Analyte sensor data evaluation and error reduction apparatus and methods

ABSTRACT

Apparatus and methods for error modeling and correction in a blood analyte sensor or system. In one exemplary embodiment, the apparatus employs: (i) a training mode of operation, whereby the apparatus conducts “machine learning” to model one or more errors (e.g., unmodeled variable system errors) associated with the blood analyte measurement process, and (ii) generation of an operational model (based at least in part on data collected/received in the training mode), which is applied to correct or compensate for the errors during normal operation and collection of blood analyte data. This enhances device signal stability and accuracy over extended periods, thereby enabling among other things extended periods of blood analyte sensor implantation, and “personalization” of the sensor apparatus to each user receiving an implant. In one variant, the blood analyte is glucose, and the implanted sensor utilizes an oxygen-based molecular measurement principle.

RELATED APPLICATIONS

This application is related to co-owned and co-pending U.S. patentapplication Ser. No. 13/559,475 filed Jul. 26, 2012 entitled “TissueImplantable Sensor With Hermetically Sealed Housing,” Ser. No.14/982,346 filed Dec. 29, 2015 and entitled “Implantable SensorApparatus and Methods”, Ser. No. 15/170,571 filed Jun. 1, 2016 andentitled “Biocompatible Implantable Sensor Apparatus and Methods”,15/197,104 filed Jun. 29, 2016 and entitled “Bio-adaptable ImplantableSensor Apparatus and Methods”, Ser. No. 15/359,406 filed Nov. 22, 2016and entitled “Heterogeneous Analyte Sensor Apparatus and Methods”, Ser.No. 15/368,436 filed Dec. 2, 2016 and entitled “Analyte Sensor ReceiverApparatus and Methods”, and Ser. No. 15/472,091 filed Mar. 28, 2017 andentitled “Analyte Sensor User Interface Apparatus and Methods,” each ofthe foregoing incorporated herein by reference in its entirety.

COPYRIGHT

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

TECHNICAL FIELD

The disclosure relates generally to the field of data analysis andprocessing, including for sensors, therapy devices, implants and otherdevices (such as those which can be used consistent with human beings orother living entities for in vivo detection and measurement or deliveryof various solutes), and in one exemplary aspect to methods andapparatus enabling the use of such sensors and/or electronic devicesfor, e.g. monitoring of one or more physiological parameters, includingthrough use of error identification, analysis, and/or correctionroutines or computer programs to enhance the accuracy and reliability ofsuch physiological parameter measurements.

DESCRIPTION OF RELATED TECHNOLOGY

Implantable electronics is a rapidly expanding discipline within themedical arts. Owing in part to significant advances in electronics andwireless technology integration, miniaturization, performance, andmaterial biocompatibility, sensors or other types of electronics whichonce were beyond the realm of reasonable use within a living subject(i.e., in vivo) can now be surgically implanted within such subjectswith minimal effect on the recipient subject, and in fact convey manyinherent benefits.

One particular area of note relates to blood analyte monitoring forsubjects, such as for example glucose monitoring for those withso-called “type 1” or “type 2” diabetes. As is well known, regulation ofblood glucose is impaired in people with diabetes by: (1) the inabilityof the pancreas to adequately produce the glucose-regulating hormoneinsulin; (2) the insensitivity of various tissues that use insulin totake up glucose; or (3) a combination of both of these phenomena. Safeand effective correction of this dysregulation requires blood glucosemonitoring.

Currently, glucose monitoring in the diabetic population is basedlargely on collecting blood by “fingersticking” and determining itsglucose concentration by conventional assay. This procedure has severaldisadvantages, including: (1) the discomfort associated with theprocedure, which should be performed repeatedly each day; (2) the nearimpossibility of sufficiently frequent sampling (some blood glucoseexcursions require sampling every 20 minutes, or more frequently, toaccurately treat); and (3) the requirement that the user initiate bloodcollection, which precludes warning strategies that rely on automaticearly detection. Using the extant fingersticking procedure, the frequentsampling regimen that would be most medically beneficial cannot berealistically expected of even the most committed patients, andautomatic sampling, which would be especially useful during periods ofsleep, is not available.

Implantable glucose sensors (e.g., continuous glucose monitoringsensors) have long been considered as an alternative to intermittentmonitoring of blood glucose levels by the fingerstick method of samplecollection. These devices may be fully implanted, where all componentsof the system reside within the body and there are no through-the-skin(i.e. percutaneous) elements, or they may be partially implanted, wherecertain components reside within the body but are physically connectedto additional components external to the body via one or morepercutaneous elements. Further, such devices provide users a great dealof freedom from potentially painful intermittent sampling methods suchas “fingersticking.” as well as having to remember and obtainself-administered blood analyte readings.

The accuracy of blood analyte detection and measurement is an importantconsideration for implanted analyte sensors, especially in the contextof current blood glucose monitoring systems (such as e.g., fullyimplanted blood glucose sensor systems), and even the future developmentof implantable blood glucose monitoring systems (such as e.g., insupport of the development of an artificial pancreas). Hence, ensuringaccurate measurement for extended periods of time (and minimizing theneed for any other confirmatory or similar analyses) is of greatsignificance. In conventional sensors, accuracy can be adverselyaffected by a myriad of factors such as e.g., random noise, foreign bodyresponse (FBR), other tissue responses, anoxia or hypoxia in the regionof the analyte sensor, blood analyte tissue dynamics, mechanicaljarring, and/or other variables.

Sensor error due to such factors can be expressed by the mean absoluterelative difference (MARD) between the sensor output and a set ofcomparison measurements (i.e., a reference measurement), or by thefrequency of outliers in the comparison. In one example, therelationship between a measured blood analyte level and a referenceblood analyte level (taken at a corresponding point in time) can beexpressed by Equation (1) below:

BA _(ref) =BA _(cal) −BA _(error) −e  Eqn. (1)

In Equation (1), “BA_(ref)” is a blood analyte level measured using anexternal source, “BA_(cal)” is a blood analyte level measured by acalibrated implanted sensor, “BA_(error)” is systematic error due tounmodeled (and possibly user-specific) system variables, and “e” iserror due to random noise.

Many known sensor systems include mechanisms and/or programming forsignal processing to reduce signal error due to random noise. Forexample, random noise error is primarily caused by random fluctuationsin electrical signals received and/or produced by the sensor components,which can be modeled and/or approximated prior to implantation. Thus,random noise can be reduced via application of one or more standardizedsignal filters (such as e.g., finite impulse response (FIR), infiniteimpulse response (IIF), Kalman, Bayesian, and/or other signal processingfilters) to the raw or calculated signal data. Accordingly, conventionalsensor systems are often pre-programmed for application of random noisesignal filters which are implemented during operation (i.e., analytedetection and reporting) of the implanted sensor system. FIG. 1 shows atypical method 100 (generalized) for operation of a conventionalimplantable analyte sensor. See e.g., U.S. patent APPLICATION Ser. No.13/742,694 entitled “Systems and Methods For Providing Sensitive andSpecific Alarms.”

However, “unmodeled” system variables (e.g., variables which are userand/or context-dependent, and hence may behave differently in eachindividual and/or context of measurement) present a particularlydifficult challenge in determining and maintaining the accuracy of bloodanalyte measurements in an implanted sensor system. For instance, someanalyte detection variables may be user-specific or context-specificbased on factors such as, inter alia, disease presentation, anatomy,physiology, metabolism or metabolic rate, medications, diet, activities,habits, climate or geographic region of residence, altitude, lifestyleof the user and/or errors introduced via an imperfect calibration of thesensor. As the foregoing unmodeled system variables primarily affectanalyte detection by implanted sensor systems in vivo (and may be highlyvariable or dynamic in nature), it is nearly impossible to pre-programor adapt a conventional sensor system with standardized mechanisms toaccount for such variables prior to implantation. While algorithms existthat are utilized for predicting a future blood glucose measurement,assuming the current measurements to be accurate, in order to predictthe likelihood of hypoglycemia/hyperglycemia (see e.g., U.S. patentapplication Ser. No. 14/659,500 entitled “Glycemic Urgency Assessmentand Alerts Interface,” and Ser. No. 14/720,668 entitled “Systems AndMethods For Dynamically And Intelligently Monitoring A Host's GlycemicCondition After an Alert is Triggered”), these approaches in no way seekto (or actually) improve the accuracy of blood glucose measurements inreal-time.

The Assignee hereof has recently developed improved methods andapparatus for implanting and measuring blood glucose level; see, interalia, U.S. patent application Ser. Nos. 13/559,475, 14/982,346,15/170,571, 15/197,104, 15/359,406, 15/368,436, and 15/472,091previously incorporated herein. However, the Assignee has furtherrecognized that areas of potential improvement over the prior art relateto, inter alia, providing an implanted analyte sensor system configuredfor improved accuracy of blood analyte level detection and reportingsuch as via e.g., in vivo adaptation to and/or modeling of theaforementioned unmodeled system variables.

For example, although conventional implantable sensor systems providelogic or programming to reduce error due to random noise, such bloodanalyte detection systems do not allow for correction of error due tounmodeled variables of the type previously described (i.e., user- and/orcontext-specific variables), which is highly desirable in that diseasepresentation, physiology, lifestyle, etc. may be different for eachuser, and may also dynamically change as a function of time or inresponse to a specific event occurring to or within the user.

Accordingly, there is a salient need for more “intelligent” anduser-specific adaptable methods and apparatus for in vivo determinationof error due to unmodeled system variables and improved accuracy ofblood analyte level calculation, and improvement of sensor and bloodanalyte measurement accuracy.

SUMMARY

The present disclosure satisfies the foregoing needs by providing, interalia, improved apparatus (including an implanted sensor and associatedlogic) and methods, for accurately providing information relating tosensed analyte levels, including for example accounting or correctingfor signal error due to one or more unmodeled variables within a livingsubject, for extended periods of time and without requiring explant ofthe sensor.

In a first aspect, an apparatus for use with an implantable bloodanalyte sensor apparatus is disclosed. In one embodiment, the apparatusincludes data processing apparatus configured for data communicationwith an analyte sensor apparatus; and a storage apparatus in datacommunication with the processing apparatus. In one variant, the storageapparatus comprises a computer program which, when executed, causes thedata processing apparatus to: (i) cause operation of the blood analytesensor apparatus in an initial training mode; (ii) based at least inpart on the operation of the sensor apparatus in the initial trainingmode, cause generation of an error correction operational model; and(iii) subsequent to generation of the error correction operationalmodel, cause operation of the analyte sensor apparatus in a detectionmode, the detection mode comprising application of the error correctionoperational model on blood analyte signal data generated by the sensorapparatus so as to correct or compensate for one or more error sources.

In varying implementations, the apparatus is disposed (i) on the sensorapparatus and integrated therewith; (ii) on a receiver apparatusdisposed external to a user within which the sensor apparatus isimplanted; or (iii) on the sensor apparatus and the causation ofgeneration of the error correction operational model comprisestransmission of data collected via the sensor apparatus during thetraining mode via a wireless interface of the sensor apparatus to anexternal receiver, the external receiver configured to perform thegeneration of the model; and the application of the generated errorcorrection model on the signal data comprises application of model datareceived via the wireless interface from the external receiver.

In one variant of the apparatus, the implanted analyte sensor includes aglucose sensor (part of a so-called “continuous glucose monitor” orCGM), and the analyte signal data are blood glucose concentration data.In one implementation, the glucose sensor is an oxygen-based glucosesensor. In another implementation, the glucose sensor is a hydrogenperoxide-based glucose sensor. In yet another implementation, theglucose sensor includes both a hydrogen peroxide-based sensor andoxygen-based glucose sensor.

In another variant of the apparatus, the operation of the apparatus inthe initial training mode includes: (i) receipt of time-stamped bloodanalyte reference data; and (ii) collection of time-stamped calculatedblood analyte sensor data. The initial training mode optionally furthercomprises collection of time-stamped data derived from one or moreancillary sensors.

In another implementation, the operation of the apparatus in the initialtraining mode includes a determination that a training data collectionthreshold has been met; and in response to the determination,termination of the training mode operation. For example, the trainingdata collection threshold may comprise a pre-determined number of datapoints, and/or a pre-determined duration of time.

In yet another variant of the apparatus, the generation of the errorcorrection operational model includes: (i) generation of blood analyteerror data via calculation of a blood analyte error value at each of aplurality of corresponding time points from the time-stamped bloodanalyte reference data and the time-stamped calculated blood analytedata; (ii) application of one or more mathematical models on at leastthe blood analyte error data and data related to one or more otherparameters; (iii) identification of at least one of the one or moreother parameters which has a high correlation to the blood analyte errordata; and (iv) utilization of the identified at least one of the one ormore other parameters, at least one of the one or more mathematicalmodels, and the blood analyte error data to generate the errorcorrection operational model.

In one implementation, the data related to one or more other parametersincludes data related to: (i) one or more times of day; (ii) datarelated to one or more blood analyte sensor elements from which bloodanalyte data originated; and/or (iii) data related to one or more rangesof blood analyte concentration.

In yet another implementation, the data related to one or more otherparameters includes data contemporaneously collected from one or moreother sensors such as e.g., a pressure sensor and/or a temperaturesensor. In another example, the one or more other sensors comprise atleast a different blood analyte sensor, such as for detection of anotherblood analyte.

In yet another variant of the apparatus, the operation of the apparatusin the detection mode further includes: (i) collection of the currentblood analyte signal data; (ii) processing of the current blood analytesignal data via the application of the error correction operationalmodel; (iii) generation of a corrected blood analyte level based atleast on the processed current blood analyte level; and (iv) output ofthe corrected blood analyte level.

In yet another variant of the apparatus, the computer program is furtherconfigured to, when executed, cause the data processing apparatus todetermine that one or more subsequent training mode criteria are met. Inone implementation, the determination includes a determination thatcurrent error data are greater than a pre-determined error threshold,and/or that a time elapsed after the initial training mode is greaterthan a pre-determined time threshold.

In another aspect of the disclosure, a method of monitoring a bloodanalyte level of a living being using a blood analyte sensing apparatusis disclosed. In one embodiment, the method includes: (i) operating theblood analyte sensing apparatus in an initial training mode; (ii) basedat least in part on the operating in the initial training mode,generating an error correction operational model; and (iii) subsequentto generating the error correction operational model, operating theblood analyte sensing apparatus in a detection mode, the operating inthe detection mode including applying the error correction operationalmodel on at least a portion of current blood analyte signal data.

In one variant of the method, the operational model is applied post hocto previously collected blood analyte data so as to correct it for oneor more errors.

In another variant of the method, the training mode is performed, andoperational model are applied, periodically while the sensing apparatusis implanted in vivo.

In a further aspect of the disclosure, a method of re-training animplanted sensor apparatus in vivo is disclosed. In one embodiment, themethod includes: (i) operating the blood analyte sensing apparatus in aninitial training mode; (ii) based at least in part on the operating inthe initial training mode, generating an error correction operationalmodel; (iii) subsequent to generating the error correction operationalmodel, substituting the generated model for a prior model within thesensor apparatus, and (iv) using the generated and substituted model onat least a portion of current blood analyte signal data. In one variant,the method further includes post hoc processing of prior generated datausing the generated and substituted model, so as to correct the priordata as compared to the prior model.

In yet another aspect of the disclosure, a method of correcting amonitored blood analyte level of a living being, using a blood analytesensing system, is disclosed. In one embodiment, the method includes:(i) receiving blood analyte reference data from an external source; (ii)collecting calculated blood analyte sensor data from an at least partlyimplanted blood analyte sensor apparatus, the blood analyte referencedata and the calculated blood analyte sensor data comprising a set oftraining data; (iii) determining that a training data threshold has beenmet; (iv) based on the determining, generating blood analyte error data;(v) analyzing, via one or more mathematical models, at least the bloodanalyte error data and the calculated blood analyte sensor data todetermine one or more parameters which are correlated with the bloodanalyte error data; (vi) based on the analyzing, generating an errorcorrection operational model; (vii) subsequent to generating theoperational model, detecting a current blood analyte level and applyingthe operational model on the current blood analyte level to produce acorrected current blood analyte level; and (viii) outputting thecorrected current blood analyte level.

In one variant, the blood analyte reference data and calculated bloodanalyte sensor data are each time-referenced (e.g., time stamped), andthe generating blood analyte error data comprises calculating a bloodanalyte error value at each of a plurality of corresponding time pointsfrom the time-stamped blood analyte reference data and the time-stampedcalculated blood analyte data.

In another variant of the method, the method further includes collectingtime-stamped other sensor data from one or more other sensor apparatus,the set of training data further comprising the other sensor data. Inthe foregoing variant, the analyzing includes analyzing, via the one ormore mathematical models, the other sensor data to determine the one ormore parameters which are correlated with the blood analyte error data.

In another aspect, a computer readable apparatus is disclosed. In oneembodiment, the computer readable apparatus comprises a storage medium(e.g., magnetic, solid state, optical, or other storage medium) havingat least one computer program disposed thereon and readable by acomputerized apparatus. The at least one computer program includes, inone variant, a plurality of instructions which, when executed on thecomputerized apparatus, cause operation of one or more blood analytesensor apparatus in a training mode, prior to operating the one or moreapparatus in an analyte detection mode. Operation in the training modeenables generation of one or more user-specific operational models (viae.g., “machine learning”), which can be used to at least partiallycorrect for systemic or other errors during analyte detection in thedetection mode.

In another aspect, a method of operating an implanted blood analytesensor is disclosed. In one embodiment, the implanted blood analytesensor is subject to one or more sources of systematic error, and themethod includes: obtaining first blood analyte data using the sensor,the obtained data subject to the one or more sources of error; obtainingreference data not subject to the one or more sources of error;evaluating the obtained blood analyte data and the reference data usingone or more machine learning algorithms; generating an operational errorcorrection model based at least on the evaluating; and applying thegenerated model to second blood analyte data to correct for at least oneof the one or more sources of error.

In one variant, the method does not require identification or humanunderstanding of one or more physical or physiologic mechanisms causingthe at least one of the one or more sources of error.

In yet another aspect, a method of compensating for or correcting errorscaused at least in part by unknown or poorly understood mechanisms orsources is disclosed.

In yet another aspect of the disclosure, a computerized networkapparatus is disclosed. In one embodiment, the network apparatusincludes a cloud-based server apparatus configured to store, andoptionally analyze, blood analyte data for a population of users (e.g.,persons with at least partly implanted blood analyte sensors, and/ortheir caregivers).

In still another aspect of the disclosure, a portable electronicapparatus is disclosed. In one embodiment, the portable electronicapparatus includes a portable receiver device configured to train animplanted blood analyte sensor via, inter alia, wireless datacommunication therewith.

Other features and advantages of the present disclosure will immediatelybe recognized by persons of ordinary skill in the art with reference tothe attached drawings and detailed description of exemplary embodimentsas given below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a logical flow diagram illustrating a typical prior art methodfor operating an at least partly implantable blood analyte monitoringsystem.

FIG. 2 is a front perspective view of one exemplary embodiment of afully implantable biocompatible sensor apparatus useful with variousaspects of the present disclosure.

FIGS. 2A-2C are top, bottom, and side elevation views, respectively, ofthe exemplary sensor apparatus of FIG. 2.

FIG. 3 is a functional block diagram illustrating one embodiment of asystem architecture for, inter alia, monitoring blood analyte levelswithin a user, useful with various aspects of the present disclosure.

FIG. 3A is a functional block diagram illustrating another embodiment ofa system architecture for, inter alia, monitoring blood analyte levelswithin a user, useful with various aspects of the present disclosure.

FIG. 3B is a functional block diagram illustrating yet anotherembodiment of a system architecture for, inter alia, monitoring bloodanalyte levels within a user, according to the present disclosure.

FIG. 4 is a logical block diagram illustrating an exemplary implantablesensor apparatus and local receiver apparatus of FIGS. 3-3B.

FIG. 4A is a logical block diagram block diagram illustrating anexemplary embodiment of the dedicated receiver and processor apparatusof FIG. 3.

FIG. 4B is a functional block diagram illustrating an exemplaryembodiment of local receiver apparatus of FIGS. 3A and 3B.

FIG. 5 is a logical flow diagram illustrating one exemplary embodimentof a generalized method of operating the implantable sensor system forblood analyte measurement according to the present disclosure.

FIG. 5A is a logical flow diagram illustrating one exemplaryimplementation of the “training mode” operation of the implantablesensor system according to the method of FIG. 5.

FIG. 5B is a logical flow diagram illustrating one exemplaryimplementation of the sensor analyte detection and output according tothe method of FIG. 5.

FIG. 5C is a logical flow diagram illustrating one exemplaryimplementation of the sensor data processing and output during “trainingmode” operation according to the method of FIG. 5B.

FIG. 5D is a logical flow diagram illustrating one exemplaryimplementation of operational model parameter selection methodologyaccording to the method of FIG. 5.

FIG. 5E is a logical flow diagram illustrating one exemplaryimplementation of operational model generation for the implantablesensor system according to the method of FIG. 5.

FIG. 5F is a logical flow diagram illustrating one exemplaryimplementation of the sensor data processing and output during“detection mode” operation according to the method of FIG. 5B.

FIG. 5G is a logical flow diagram illustrating one exemplaryimplementation for determination of whether re-training criteria are metfor the implantable sensor system according to the method of FIG. 5.

FIG. 6 is a graphical representation of an exemplary decision tree usedin model generation according to one embodiment of the presentdisclosure, wherein each end-node predicts a specific error (or source).

FIG. 7 is a logical flow diagram illustrating one exemplaryimplementation of the generalized method of operating the implantablesensor system for blood analyte measurement according to FIG. 5, in thecontext of an implantable oxygen-based blood glucose sensor having aplurality of detector pairs.

FIG. 8 is a logical flow diagram illustrating another exemplaryembodiment of a population-based method of operating the implantablesensor system for blood analyte measurement according to the presentdisclosure.

All Figures © Copyright 2016-2017 GlySens Incorporated. All rightsreserved.

DETAILED DESCRIPTION

Reference is now made to the drawings, wherein like numerals refer tolike parts throughout.

Overview

One aspect of the present disclosure leverages Assignee's recognitionthat many of the above-described disabilities of the prior art inproviding accurate blood analyte data are due to a lack of an ability toaccount or correct for “unmodeled” variable errors in calculation andoutput of blood analyte level. Further, the Assignee hereof recognizesthat error in a blood analyte sensor signal due to such unmodeledvariables is often user-specific and/or only determinable in vivo (i.e.,after implantation of the sensor). Such disabilities of the prior artcan be mitigated or even completely eliminated via personalized anddynamic detection of blood analyte level and compensation for associatederrors, including when the sensor is implanted within the user.

Accordingly, the apparatus and methods of the present disclosure, in oneexemplary embodiment, employ (i) a training mode of operation, wherebythe apparatus (or processing logic associated therewith, whetheron-board or off-board) conducts “machine learning” to model one or moreerrors (e.g., unmodeled variable system errors) associated with theblood analyte measurement process, and (ii) generation of an operationalmodel (based at least in part on data collected/received in the trainingmode), which is applied to correct or compensate for the errors duringnormal operation and collection of blood analyte data.

The methods and apparatus of the present disclosure also, in oneembodiment, leverage the only recently-available capability forlong-term implantation of blood analyte sensing devices (such as theoxygen-based blood glucose sensing device manufactured by the Assigneehereof), to yet further enhance device signal stability and accuracyover extended periods of implantation, including through“personalization” of the sensor apparatus via the aforementionedtraining mode and subsequent operational model generation.

In one embodiment, the aforementioned implantable sensor (e.g., anoxygen-based sensor for detection of blood glucose level) is used inconjunction with either a local receiver apparatus (e.g., a wearablelocal receiver apparatus) in data communication with a parent platform(e.g., a user's mobile device), or a dedicated receiver and processorapparatus. The sensor and/or the receiver apparatus are configured foroperation in a “training mode” after implantation of the sensor. Duringoperation in the “training mode”, the sensor system collects in oneimplementation and calculates time-stamped blood analyte level data(BA_(cal) data), and receives external time-stamped blood analyte levelreference data (BA_(ref) data) such as e.g., blood analyte data obtainedfrom “fingersticking”, or other laboratory or in situ testing. Thesystem may additionally collect and utilize other non-BA_(cal) data,such as e.g., data collected from each of the other sensors,non-BA_(cal) data collected from the implanted sensor, and/or data inputby a user or medical professional.

After collection of a statistically relevant amount of data, the bloodanalyte reference data and the calculated blood analyte level data areutilized to calculate blood analyte error data (BA_(error) data), andone or more parameters (e.g., time of day, range of the target bloodanalyte concentration, temperature, sensor element or origin, heartrate, motion, pressure exerted on the implanted sensor, other bloodanalyte concentrations, other sensor detector signals or featuresthereof, such as for example first or second derivatives of sensorsignals, or measures of sensor signal variability) which have a highcorrelation to blood analyte error are identified via application of oneor more “machine learning algorithms.” This information is used in oneembodiment to generate a user-specific operational model, which issubsequently used during normal operation of the sensor system in ananalyte detection and reporting mode to predict error due to unmodeledsystem variables (i.e., user and/or context-specific variables). Thus,the output blood analyte level readings advantageously account and/orcorrect for the predicted unmodeled variable error (and, in someexamples, random noise error), thereby providing significantly improvedaccuracy in terms of, e.g., mean absolute relative difference (MARD)between the sensor output and a comparison or calibrated measurement, orby the frequency of outliers in such comparisons or calibrations, ascompared to conventional implantable blood analyte sensor systems.

In another embodiment, the machine learning or training is conductedwithout reference to external data or ancillary sensor data; i.e., basedonly on the generated sensor data itself, and analysis thereof.

Moreover, exemplary embodiments of the methods and apparatus disclosedherein need not have any fundamental or even basic knowledge of themechanism(s) underlying the unmodeled variables/errors; rather, thesystem can advantageously identify, model and compensate for such errorswithout having to understand how or why the errors occur (such as in thecase of a poorly understood or previously unknown physiologic phenomenonoccurring within the target user).

Additionally, the foregoing sensor training mode can be repeated (asnecessary, on a prescribed schedule, or according to yet other basis) tomaintain sensor accuracy throughout the implantation lifetime, even asdisease presentation or other physiological or lifestyle characteristicsof the user change over that same time.

Methods of use of the aforementioned blood analyte detection system, aswell as other aspects, are also disclosed herein.

Detailed Description of Exemplary Embodiments

Exemplary embodiments of the present disclosure are now described indetail. While these embodiments are primarily discussed in the contextof a fully implantable glucose sensor, such as those exemplaryembodiments described herein, and/or those set forth in U.S. PatentApplication Publication No. 2013/0197332 filed Jul. 26, 2012 entitled“Tissue Implantable Sensor With Hermetically Sealed Housing;” U.S. Pat.No. 7,894,870 to Lucisano et al. issued Feb. 22, 2011 and entitled“Hermetic Implantable Sensor;” U.S. Patent Application Publication No.2011/0137142 to Lucisano et al. published Jun. 9, 2011 and entitled“Hermetic Implantable Sensor;” U.S. Pat. No. 8,763,245 to Lucisano etal. issued Jul. 1, 2014 and entitled “Hermetic Feedthrough Assembly forCeramic Body;” U.S. Patent Application Publication No. 2014/0309510 toLucisano et al. published Oct. 16, 2014 and entitled “HermeticFeedthrough Assembly for Ceramic Body;” U.S. Pat. No. 7,248,912 to Goughet al. issued Jul. 24, 2007 and entitled “Tissue Implantable Sensors forMeasurement of Blood Solutes;” and U.S. Pat. No. 7,871,456 to Gough etal. issued Jan. 18, 2011 and entitled “Membranes with ControlledPermeability to Polar and Apolar Molecules in Solution and Methods ofMaking Same;” and U.S. Patent Application Publication No. 2013/0197332to Lucisano et al. published Aug. 1, 2013 and entitled “TissueImplantable Sensor with Hermetically Sealed Housing;” PCT PatentApplication Publication No. 2013/016573 to Lucisano et al. publishedJan. 31, 2013 and entitled “Tissue Implantable Sensor with HermeticallySealed Housing,” each of the foregoing incorporated herein by referencein its entirety, as well as those of U.S. patent application Ser. Nos.13/559,475, 14/982,346, 15/170,571, and 15/197,104, 15/359,406,15/368,436, and 15/472,091 previously incorporated herein, it will berecognized by those of ordinary skill that the present disclosure is notso limited. In fact, the various aspects of the disclosure are usefulwith, inter alia, other types of implantable sensors and/or electronicdevices.

Further, while the following embodiments describe specificimplementations of e.g., biocompatible oxygen-based multi-sensor elementdevices for measurement of glucose, having specific configurations,protocols, locations, and orientations for implantation (e.g., proximatethe waistline on a human abdomen with the sensor array disposedproximate to fascial tissue; see e.g., U.S. patent application Ser. No.14/982,346 filed Dec. 29, 2015 and entitled “Implantable SensorApparatus and Methods” previously incorporated herein), those ofordinary skill in the related arts will readily appreciate that suchdescriptions are purely illustrative, and in fact the methods andapparatus described herein can be used consistent with, and withoutlimitation: (i) in living beings other than humans; (ii) other types orconfigurations of sensors (e.g., other types, enzymes, and/or theoriesof operation of glucose sensors, sensors other than glucose sensors,such as e.g., sensors for other analytes such as urea, lactate); (iii)other implantation locations and/or techniques (including withoutlimitation transcutaneous or non-implanted devices as applicable);and/or (iv) devices intended to deliver substances to the body (e.g.implanted drug pumps); and/or other devices (e.g., non-sensors andnon-substance delivery devices).

As used herein, the term “analyte” refers without limitation to asubstance or chemical species that is of interest in an analyticalprocedure. In general, the analyte itself may or may not be directlymeasurable, in cases where it is not, a measurement of the analyte(e.g., glucose) can be derived through measurement of chemicalconstituents, components, or reaction byproducts associated with theanalyte (e.g., hydrogen peroxide, oxygen, free electrons, etc.).

As used herein, the terms “detector” and “sensor” refer withoutlimitation to a device having one or more elements (e.g., detectorelement, sensor element, sensing elements, etc.) that generate, or canbe made to generate, a signal indicative of a measured parameter, suchas the concentration of an analyte (e.g., glucose) or its associatedchemical constituents and/or byproducts (e.g., hydrogen peroxide,oxygen, free electrons, etc.). Such a device may be based onelectrochemical, electrical, optical, mechanical, thermal, or otherprinciples as generally known in the art. Such a device may consist ofone or more components, including for example, one, two, three, or fourelectrodes, and may further incorporate immobilized enzymes or otherbiological or physical components, such as membranes, to provide orenhance sensitivity or specificity for the analyte.

As used herein, the terms “orient,” “orientation,” and “position” refer,without limitation, to any spatial disposition of a device and/or any ofits components relative to another object or being, and in no wayconnote an absolute frame of reference.

As used herein, the terms “top,” “bottom,” “side,” “up,” “down,” and thelike merely connote, without limitation, a relative position or geometryof one component to another, and in no way connote an absolute frame ofreference or any required orientation. For example, a “top” portion of acomponent may actually reside below a “bottom” portion when thecomponent is mounted to another device (e.g., host sensor).

As used herein the term “parent platform” refers without limitation toany device, group of devices, and/or processes with which a client orpeer device (including for example the various embodiments of localreceiver described here) may logically and/or physically communicate totransfer or exchange data. Examples of parent platforms can include,without limitation, smartphones, tablet computers, laptops, smartwatches, personal computers/desktops, servers (local or remote),gateways, dedicated or proprietary analyte receiver devices, medicaldiagnostic equipment, and even other local receivers acting in apeer-to-peer or dualistic (e.g., master/slave) modality.

As used herein, the term “application” (or “app”) refers generally andwithout limitation to a unit of executable software that implements acertain functionality or theme. The themes of applications vary broadlyacross any number of disciplines and functions (such as on-demandcontent management, e-commerce transactions, brokerage transactions,home entertainment, calculator etc.), and one application may have morethan one theme. The unit of executable software generally runs in apredetermined environment; for example, the Java® environment.

As used herein, the term “computer program” or “software” is meant toinclude any sequence or human or machine cognizable steps which performa function. Such program may be rendered in virtually any programminglanguage or environment including, for example, C/C++, Fortran, COBOL,PASCAL, assembly language, markup languages (e.g., HTML, SGML, XML,VoXML), and the like, as well as object-oriented environments such asthe Common Object Request Broker Architecture (CORBA), Java® (includingJ2ME, Java Beans, etc.) and the like.

As used herein, the terms “Internet” and “internet” are usedinterchangeably to refer to inter-networks including, withoutlimitation, the Internet. Other common examples include but are notlimited to: a network of external servers, “cloud” entities (such asmemory or storage not local to a device, storage generally accessible atany time via a network connection, or cloud-based or distributedprocessing or other services), service nodes, access points, controllerdevices, client devices, etc.

As used herein, the term “memory” includes any type of integratedcircuit or other storage device adapted for storing digital dataincluding, without limitation, ROM, PROM, EEPROM, DRAM, SDRAM, DDR/2SDRAM, EDO/FPMS, RLDRAM, SRAM, “flash” memory (e.g., NAND/NOR), 3Dmemory, and PSRAM.

As used herein, the terms “microprocessor” and “processor” or “digitalprocessor” are meant generally to include all types of digitalprocessing devices including, without limitation, digital signalprocessors (DSPs), reduced instruction set computers (RISC),general-purpose (CISC) processors, microprocessors, gate arrays (e.g.,FPGAs), PLDs, state machines, reconfigurable computer fabrics (RCFs),array processors, secure microprocessors, and application-specificintegrated circuits (ASICs). Such digital processors may be contained ona single unitary integrated circuit (IC) die, or distributed acrossmultiple components.

As used herein, the term “network” refers generally to any type oftelecommunications or data network including, without limitation, hybridfiber coax (HFC) networks, satellite networks, telco networks, and datanetworks (including MANs, WANs, LANs, WLANs, internets, and intranets),cellular networks, as well as so-called “mesh” networks and “IoTs”(Internet(s) of Things). Such networks or portions thereof may utilizeany one or more different topologies (e.g., ring, bus, star, loop,etc.), transmission media (e.g., wired/RF cable, RF wireless, millimeterwave, optical, etc.) and/or communications or networking protocols.

As used herein, the term “interface” refers to any signal or datainterface with a component or network including, without limitation,those of the FireWire (e.g., FW400, FW800, etc.), USB (e.g., USB 2.0,3.0. OTG), Ethernet (e.g., 10/100, 10/100/1000 (Gigabit Ethernet),10-Gig-E, etc.), MoCA, LTE/LTE-A, Wi-Fi (802.11), WiMAX (802.16),Z-wave, PAN (e.g., 802.15)/Zigbee, Bluetooth, Bluetooth Low Energy (BLE)or power line carrier (PLC) families.

As used herein, the term “storage” refers to without limitation computerhard drives, memory, RAID devices or arrays, optical media (e.g.,CD-ROMs, Laserdiscs, Blu-Ray, etc.), solid state devices (SSDs), flashdrives, cloud-hosted storage, or network attached storage (NAS), or anyother devices or media capable of storing data or other information.

As used herein, the term “Wi-Fi” refers to, without limitation and asapplicable, any of the variants of IEEE-Std. 802.11 or related standardsincluding 802.11 a/b/g/n/s/v/ac or 802.11-2012/2013, as well as Wi-FiDirect (including inter alia, the “Wi-Fi Peer-to-Peer (P2P)Specification”, incorporated herein by reference in its entirety).

As used herein, the term “wireless” means any wireless signal, data,communication, or other interface including without limitation Wi-Fi,Bluetooth (including BLE or “Bluetooth Smart”), 3G (3GPP/3GPP2),HSDPA/HSUPA, TDMA, CDMA (e.g., IS-95A, WCDMA, etc.), FHSS, DSSS, GSM,PAN/802.15, WiMAX (802.16), 802.20, Zigbee®, Z-wave, narrowband/FDMA,OFDM, PCS/DCS, LTE/LTE-A, analog cellular, CDPD, satellite systems,millimeter wave or microwave systems, acoustic, and infrared (i.e.,IrDA).

Exemplary Implantable Sensor

Referring now to FIGS. 2-2C, one exemplary embodiment of a sensorapparatus useful with various aspects of the present disclosure is shownand described.

As shown in FIGS. 2-2C, the exemplary sensor apparatus 200 comprises asomewhat planar housing structure 202 with a sensing region 204 disposedon one side thereof (i.e., a top face 202 a). As described in greaterdetail below with respect to FIGS. 4-5, the exemplary substantiallyplanar shape of the housing 202 provides mechanical stability for thesensor apparatus 200 after implantation, thereby helping to preserve theorientation of the apparatus 200 and mitigate any tissue responseinduced by movement of the apparatus while implanted. Notwithstanding,the present disclosure contemplates sensor apparatus of shapes and/orsizes other than that of the exemplary apparatus 200.

The sensor apparatus of FIGS. 2-2C further includes a plurality ofindividual sensor elements 206 with their active surfaces disposedsubstantially within the sensing region 204 on the top face 202 a of theapparatus housing. In the exemplary embodiment (i.e., an oxygen-basedglucose sensor), the eight (8) sensing elements 206 are grouped intofour pairs, one element of each pair an active or “primary” sensor withenzyme matrix, and the other a reference or “secondary” (oxygen) sensor.Exemplary implementations of the sensing elements and their supportingcircuitry and components are described in, inter alia, U.S. Pat. No.7,248,912, previously incorporated herein. It will be appreciated,however, that the type and operation of the sensor apparatus may vary;i.e., other types of sensor elements/sensor apparatus, configurations,and signal processing techniques thereof may be used consistent with thevarious aspects of the present disclosure, including, for example,signal processing techniques based on various combinations of signalsfrom individual elements in the otherwise spatially-defined sensingelements pairs.

The illustrated embodiment of FIGS. 2-2C includes a sensing region 204which facilitates some degree of “interlock” of the surrounding tissue(and any subsequent tissue response generated by the host) so as toensure direct and sustained contact between the sensing region 204 andthe blood vessels of the surrounding tissue during the entire term ofimplantation (as well as advantageously maintaining contact between thesensing region 204 and the same tissue; i.e., without significantrelative motion between the two).

The sensor apparatus 200 also includes in the exemplary embodiment awireless radio frequency transmitter (or transceiver, depending ifsignals are intended to be received by the apparatus), not shown. Asdescribed in the aforementioned documents incorporated herein, thetransmitter/transceiver may be configured to transmit modulated radiofrequency signals to an external receiver/transceiver, such as adedicated receiver device, or alternatively a properly equipped consumerelectronic device such as a smartphone or tablet computer. Moreover, thesensor apparatus 200 may be configured to transmit signals to (whetherin conjunction with the aforementioned external receiver, or in thealternative) an at least partly implanted or in vivo receiving device,such as an implanted pump or other medication or substance deliverysystem (e.g., an insulin pump or dispensing apparatus), embedded“logging” device, or other. It is also appreciated that other forms ofwireless communication may be used for such applications, including forexample inductive (electromagnetic induction) based systems, or eventhose based on capacitance or electric fields, or even optical (e.g.,infrared) systems where a sufficiently clear path of transmission andreception exists, such as two devices in immediately adjacentdisposition, or even ultrasonic systems where the two devices aresufficiently close and connected by sound-conductive media such as bodytissues or fluids, or a purposely implanted component.

The sensor apparatus of FIGS. 2-2C also includes a plurality (three inthis instance) of tabs or anchor apparatus 213 disposed substantiallyperipheral on the apparatus housing. These anchor apparatus provide theimplanting surgeon with the opportunity to anchor the apparatus to theanatomy of the living subject, so as to frustrate translation and/orrotation of the sensor apparatus 200 within the subject immediatelyafter implantation but before any tissue response (e.g., FBR) of thesubject has a chance to immobilize (such as via interlock with thesensing region of the apparatus. See e.g., U.S. patent application Ser.No. 14/982,346 filed Dec. 29, 2015 and entitled “Implantable SensorApparatus and Methods” previously incorporated herein, for additionaldetails and considerations regarding the aforementioned anchor apparatus213 (which may include, for example features to receive sutures(dissolvable or otherwise), tissue ingrowth structures, and/or thelike).

Moreover, another exemplary embodiment of the sensor apparatus 200described herein may include either or both of: (i) multiple detectorelements with respective “staggered” ranges/rates of detection operatingin parallel, and/or (ii) multiple detector elements with respective“staggered” ranges/rates of detection that are selectively switchedon/off in response to, e.g., the analyte concentration reaching aprescribed upper or lower threshold, as described in the foregoingpatent application Ser. No. 15/170,571 previously incorporated herein.

The present disclosure further contemplates that such thresholds orbounds: (i) can be selected independent of one another; and/or (ii) canbe set dynamically while the apparatus 300 is implanted. For example, inone scenario, operational detector elements are continuously orperiodically monitored to confirm accuracy, and/or detect anydegradation of performance (e.g., due to equipment degradation,progressive FBR affecting that detector element, etc.); when suchdegradation is detected, affecting say a lower limit of analyteconcentration that can be detected, that particular detector element canhave its lower threshold adjusted upward, such that handoff to anotherelement capable of more accurately monitoring concentrations in thatrange. Note that these thresholds or bounds are to be distinguished fromthose associated with the user interface (UI) described subsequentlyherein, the latter being independent of the datasource/capability/configuration associated with the sensor detectorelements.

It will be appreciated that the relatively smaller dimensions of thesensor apparatus (as compared to many conventional implantdimensions)—on the order of 40 mm in length (dimension “a” on FIGS.2A-2C) by 25 mm in width (dimension “b” on FIGS. 2A-2C) by 10 mm inheight (dimension “c” on FIGS. 2A-2C) - may reduce the extent of injury(e.g., reduced size of incision, reduced tissue disturbance/removal,etc.) and/or the surface area available for blood/tissue and sensormaterial interaction, which may in turn reduce intensity and duration ofthe host wound healing response. It is also envisaged that as circuitintegration is increased, and component sizes (e.g., Lithium or otherbatteries) decrease, and further improvements are made, the sensor mayincreasingly be appreciably miniaturized, thereby further leveragingthis factor.

System Architecture—

As described elsewhere herein, exemplary embodiments of the presentdisclosure utilize machine learning algorithms to, inter alia,compensate for systemic errors, whether well modeled, or unmodeled,affecting a blood analyte sensor apparatus. Notably, such algorithms maybe implemented in computerized logic (software, firmware, or evenhardware) that is resident in any number of different locations withinthe system, including: (i) within the implanted sensor apparatus itself;(ii) “off-board” the sensor apparatus, such as in an external receiverapparatus (examples of which are described below); (iii) off-board, in aconnected “cloud” entity; and/or combinations of the foregoing (e.g., ina distributed computing architecture). Accordingly, the followingembodiments are merely examples of such types of architectures, and thevarious aspects of the present disclosure are in no way limited thereto.

Referring now to FIG. 3, one embodiment of a system architecture for,inter alia, monitoring blood analyte levels within a user, useful withthe machine learning-based methods and apparatus of present disclosure,is described in detail. As depicted in FIG. 3, the system architecturecomprises a sensor apparatus 200 (e.g., that of FIGS. 2-2C discussedabove, or yet other types of device) associated with a user, a receiverand processor apparatus 450 and a network entity 700. The sensorapparatus 200 in this embodiment communicates with the receiver andprocessor apparatus 450 via a wireless interface (described in detailbelow) through the user's tissue boundary 101. The receiver andprocessor apparatus 450 may also, if desired, communicate with one ormore network entities 800 via a LAN/WLAN, MAN, or other topology, suchas for “cloud” data storage, analysis, convenience of access at otherlocations/synchronization with other user platforms, etc.

As shown in FIG. 3A, another exemplary system architecture 310 comprisesa sensor apparatus 200 (e.g., that of FIG. 2 discussed above, or yetother types of device) associated with a user, a local receiver 400, aparent platform 700, and a network entity 800. The sensor apparatus 200in this embodiment communicates with the local receiver 400 via awireless interface (described in detail below) through the user's tissueboundary 101. The local receiver 400 communicates (e.g., wirelessly)with the one or more parent platform(s) 600 via a PAN (e.g., Bluetoothor similar) RF interface, as discussed in greater detail below. Theparent platform 700 may also, if desired, communicate with one or morenetwork entities 800 via a LAN/WLAN, MAN, or other topology, such as for“cloud” data storage, analysis, convenience of access at otherlocations/synchronization with other user platforms, etc.

In exemplary system architecture shown in FIG. 3A, the local receiver400 is a lower profile and/or wearable local receiver apparatus (e.g.,small profile wristband, fob, tooth or other implant, skin-adherentpatch, ear “bud” or plug, a ring worn in the finger, etc.) as comparedto the receiver and processor apparatus 450 shown in FIG. 3. The localreceiver apparatus 400 can include a user alert mechanism and/or minimaluser interface (UI) such as, e.g., a substantially flat and flexible LED(e.g., graphene-based), AMOLED, or OTFT (organic thin-film transistor)display device, haptic mechanism (e.g., a vibration mechanism), auditorymechanism (e.g., speakers), and/or other user-signaling capabilities andmechanisms (e.g., indicator lights). Various exemplary configurationsfor the local receiver 400 are shown and described in U.S. patentapplication Ser. No. 15/368,436 filed Dec. 2, 2016 previouslyincorporated herein.

As indicated in FIG. 3A, the communications between the sensor 200 andthe local receiver 400 are generally continuous and reliable in nature(similar to communication between the sensor 200 and the receiver andprocessor apparatus 450 of FIG. 3). In contrast, the communicationbetween the local receiver 400 and the parent platform(s) can be eithercontinuous or opportunistic (or any desired combination thereof betweenthe various components of each) in nature. Such opportunisticcommunication can be a significant advantage of the architecture 300over the prior art; i.e., the ability for the sensor 200 and a reducedform-factor local receiver 400 to communicate regularly to enablereliable and effectively constant monitoring and user awareness of theirblood analyte (e.g., glucose) level, without being “tethered” to larger,bulkier, and perhaps activity-limiting parent devices, including forextended periods of time.

Specifically, in the illustrated architecture 310, the local receiver400 acts as a reduced- or limited-functionality indicator and monitorfor the user that reliably operates for comparatively extended periodsof time without external input or calibration, thereby obviating theparent platform during those periods. As described later herein, thereduced form factor advantageously enables the user to further: (i)engage in activities which they could not otherwise engage in if“tethered” to the parent platform, and (ii) effortlessly keep the localreceiver with them at all times, and obtain reliable blood analyte dataand other useful information (e.g., trend, rate of change (ROC), andother sensor-data derived parameters), in a non-obtrusive (or evencovert) manner.

In the example of system architecture 310, when communication betweenthe parent platform 600 and the local receiver does occur, the exemplaryarchitecture 310 enables two-way data transfer, including: (i) transferof stored data extracted from the sensor wireless transmissions to thelocal receiver, to the parent platform for archiving, analysis, transferto a network entity, etc.; (ii) transfer of sensor-specificidentification data and/or local receiver-specific data between thelocal receiver and the parent platform; (iii) transfer of externalcalibration data (e.g., derived from an independent test method such asa fingerstick or blood glucose monitor and input either automatically ormanually to the parent platform) from the parent to the local receiver;and (iv) transfer of local receiver configuration or other data (e.g.,software/firmware updates, user-prescribed receiver settings for alarms,warning/buffer values, indication formats or parameters, historicalblood analyte levels for the user, results of analysis by the parent 700or network entity 800 of such data, diagnoses, security or datascrambling/encryption codes or keys, etc.) from the parent 600 to thelocal receiver 400.

FIG. 3B shows yet another embodiment of a system architecture 320 for,inter alia, monitoring blood analyte levels within a user, useful withthe present disclosure. As shown in FIG. 3B, the architecture 320comprises a sensor apparatus 200 associated with a user, a localreceiver 400, and calibration sensor platform 900. As with theembodiment of FIG. 3A, the sensor apparatus 200 in this embodimentcommunicates with the local receiver 400 via a wireless interfacethrough the user's tissue boundary 101. The local receiver 400communicates (e.g., wirelessly) with one or more calibration sensorplatform(s) or CSPs 900 via a PAN (e.g., Bluetooth or similar) RFinterface, as discussed in greater detail below, or via IR (e.g.,IrDA-compliant), optical or other short-range communication modality. Asdescribed in greater detail below, the CSP 900 in the illustratedembodiment comprises a calibration data source for the local receiver400, which may stand in the place of the more fully-functioned parentplatform 700 for at least provision of calibration data.

As indicated in FIG. 3B, the communications between the sensor 200 andthe local receiver 400 are again generally continuous or regular innature while the communication between the local receiver 400 and theCSP 900 is purposely opportunistic in nature.

When the opportunistic communication between the CSP 900 and the localreceiver does occur, the exemplary architecture 310 enables at leastone-way data transfer, including transfer of external calibration data(e.g., derived from an independent test method such as the “fingerstick”or other form of blood analyte sensor 902 of the CSP 900 from the CSP tothe local receiver 400. In an exemplary implementation, the CSP 900comprises a “smart” fingerstick apparatus, including at least (i)sufficient onboard processing capability to generate calibration datauseful with the local receiver 400 based on signals or data output fromthe blood sensor 902, and (ii) a data interface to enable transmissionof the data to the local receiver 400. In one configuration, the sensor902 includes a needle or lancet apparatus 904 which draws a sample ofthe user's blood for the sensor 902 to analyze. Electronic glucose“fingerstick” apparatus (including those with replaceable single-uselancets) and re-usable electronic components are well known in therelevant arts, and accordingly not described further herein. See e.g.,U.S. Pat. No. 8,357,107 to Draudt, et al. issued Jan. 22, 2013 andincorporated herein by reference in its entirety, for one example ofsuch technology. The sensor 902 analyzes the extracted blood obtainedvia the lancet 904 and (via the onboard processing) produces dataindicative of a blood glucose level (or at least generates data fromwhich such level may be derived), such data being provided to thecommunications interface 906 for transfer to the local receiver 400. Thetransmitted data are then utilized within the local receiver 400 forcalibration of the data generated by the implanted sensor 200.

In one variant, the interface 906 comprises a Bluetooth-compliantinterface, such that a corresponding Bluetooth interface of the localreceiver can “pair” with the CSP 900 to effect transfer of thecalibration data wirelessly. Hence, the user with implanted sensor 200can simply use a fingerstick-based or other type of external calibrationdata source to periodically (e.g., once weekly) confirm the accuracyand/or update the calibration of the implanted sensor 200 viaopportunistic communication between the local receiver 400 (e.g., smallprofile wristband, fob, etc.) and CSP 900 when convenient for the user.Advantageously, many persons with diabetes possess such electronicfingerstick-based devices, and wireless communication capability isreadily added thereto by the manufacturer at little additional cost.

In another variant, the communications interface comprises an IR oroptical “LOS” interface such as one compliant with IrDA technology, suchthat the user need merely establish a line-of-sight path between theemitter of the CSP 900 and the receptor of the local receiver 400, akinto a television remote control. As yet another alternative, a near-fieldcommunication (NFC) antenna may be utilized to transfer data wirelesslybetween the apparatus 400, 900 when placed in close range (i.e.,“swiped”). Yet other communication modalities will be recognized bythose of ordinary skill given the present disclosure. Additionalfunctionalities of the local receiver 400 and parent platform 700 aredescribed in U.S. patent application Ser. No. 15/368,436 filed Dec. 2,2016 and previously incorporated herein.

It will be appreciated that the architectures shown in FIGS. 3-3B are inno way exclusive of one another, and in fact may be used together (suchas at different times and/or via different use cases). For example, CSP900 can be used in combination with receiver and processor apparatus 450for opportunistic communication of calibration data. Myriad otherpermutations of use cases involving one or more of the variouscomponents 200, 400, 450, 700, 800, 900 are envisaged by the presentdisclosure. Various system architecture and communication pathways ofsystem components are shown and described in U.S. patent applicationSer. No. 15/368,436 filed Dec. 2, 2016 and previously incorporatedherein.

FIG. 4 is a functional block diagram illustrating an exemplaryimplantable sensor apparatus 200 and local receiver and processorapparatus 450 or local receiver apparatus 400 according to oneembodiment of the present disclosure. As shown, the sensor apparatus 200includes a processor 210 (e.g., digital RISC, CISC, and/or DSP device),and/or a microcontroller (not shown), memory 216, software/firmware 218operative to execute on the processor 210 and stored in e.g., a programmemory portion of the processor 210 (not shown), or the memory 216, amass storage device 220 (e.g., NAND or NOR flash, SSD, etc. to storecollected raw or preprocessed data or other data of interest), one ormore analyte detectors 226, a wireless interface 228 (e.g., narrowband,PAN such as Bluetooth, or other, described below), a power supply 230(e.g., a primary Lithium or rechargeable NiMH or Lithium ion battery).

Also depicted in FIG. 4, the sensor apparatus 200 can optionally includeone or more additional internal sensors 232. The internal sensor(s) 232may be any of a temperature sensor, an accelerometer, a pressure sensor,a pulse meter, a conductivity meter, pH (i.e., hydronium ionconcentration), electric field sensor, and/or other (non-target)analyte-detection sensors (e.g., other blood analytes). In an alternateembodiment, the one or more internal sensors can be located in aseparate implantable apparatus positioned proximate to the sensor 200during implantation.

As can be appreciated by those of ordinary skill given the presentdisclosure, any number of different hardware/software/firmwarearchitectures and component arrangements can be utilized for the sensorapparatus 200 of FIG. 4, the foregoing being merely illustrative. Forinstance, a less-capable (processing, sensing, and/or data storage-wise)or “thinner” configuration may be used (e.g., excluding the one or moreadditional internal sensors), or additional functionality not shownadded (e.g., including additional types of other sensors and/orcomponents).

Receiver Apparatus—

Referring now to FIGS. 4A-4B, various embodiments of the receiverapparatus 400 and 450 shown in FIGS. 3-3C herein are described indetail.

FIG. 4A depicts a functional block diagram of one embodiment of thereceiver and processor apparatus 450 (i.e., a dedicated receiverapparatus), in wireless communication with the analyte sensor 200 ofFIG. 3C via the interposed tissue (boundary) 101. As noted previously,the present disclosure contemplates use of partially-implanted (e.g.,transcutaneous or percutaneous) or even non-implanted analyte sensordevices, as well as the fully-implanted device (e.g., sensor apparatus200 of FIGS. 2-2C).

As shown in FIG. 4A, the dedicated receiver apparatus 450 includes aprocessor 404 (e.g., digital RISC, CISC, and/or DSP device), and/or amicrocontroller (not shown), memory 406, software/firmware 408 operativeto execute on the processor 404 and stored in e.g., a program memoryportion of the processor 404 (not shown), or the memory 406, a massstorage device 420 (e.g., NAND or NOR flash, SSD, etc. to store receivedraw or preprocessed data, post-processed data, or other data ofinterest), a wireless interface 416 (e.g., narrowband or other,described below) for communication with the sensor apparatus 200, acommunications (e.g., wireless) interface 414 for communication with thenetwork entity 800 (if desired), a power supply 430 (e.g., NiMH orLithium ion battery, or other as described below), and a graphicaldisplay device 440. The dedicated receiver apparatus 450 can optionallyinclude one or more output device(s) 410 (i.e., other types of useroutputs in addition to the graphical display device 440) forcommunication of the desired data (e.g., glucose level, rate, trend,battery “low” alerts, etc.) in addition to the display 440. As describedin greater detail subsequently herein the output device(s) may includefor example visual, audible, and/or tactile (e.g., haptic) modalities ormechanisms, which can be used alone or in concert depending on usercontext, desired functionality, and receiver and processor apparatusconfiguration.

Additionally, the apparatus 450 can optionally include one or moreadditional external sensors 432. The one or more external sensors 432may be any of a temperature sensor, an accelerometer, a pulse meter, ablood pressure sensor, and/or other types of sensors. In one example,the external sensors 432 of the receiver 450 can be used in place of theone or more internal sensors 232 of the sensor apparatus 200. In anotherexample, the external sensors 432 can be used cooperatively with theinternal sensors 232 to, inter alia, generate a duplicate set of dataand/or a complimentary set of data collected from the internal sensorsof the implanted sensor device.

In one specific implementation, the external sensors 432 can becalibrated to the internal sensors 232 (such as e.g., during “trainingmode” operation of the sensor system), In such an implementation,subsequent “other sensor” data (i.e., data collected from sensors otherthan the target blood analyte sensor) can be collected from the externalsensors 432 during operation of the sensor system in the “detectionmode”. Further, the internal sensors can be substantially turned “off”,thereby e.g., decreasing power usage and/or processing requirements ofthe implanted sensor.

FIG. 4B is a functional block diagram showing one embodiment of thelocal receiver apparatus 400, in wireless communication with the parentplatform 700 and the analyte sensor 200 (discussed supra) of FIG. 4 viathe interposed tissue (boundary) 101.

Similar to the receiver and processor apparatus 450, the local receiverapparatus 400 includes a processor 404 (e.g., digital RISC, CISC, and/orDSP device), and/or a microcontroller (not shown), memory 406,software/firmware 408 operative to execute on the processor 404 andstored in e.g., a program memory portion of the processor 404 (notshown), or the memory 406, a mass storage device 420 (e.g., NAND or NORflash, SSD, etc. to store received raw or preprocessed data,post-processed data, or other data of interest), a wireless interface416 (e.g., narrowband or other, described below) for communication withthe sensor apparatus 200, a communications (e.g., wireless) interface414 for communication with the parent platform 700 and/or the networkentity 800 (if desired), and a power supply 430 (e.g., NiMH or Lithiumion battery, or other as described below). The apparatus 400 alsoincludes one or more output device(s) 410 (such as e.g., visual,audible, and/or haptic modalities or alert mechanisms) for communicationof the desired data (e.g., glucose level, rate, trend, battery “low”alerts, etc.). Additionally, the apparatus 400 can optionally includeone or more external sensors 432, such as those described above withreference to FIG. 4. In an alternate embodiment, the one or more othersensors can be located in a separate implantable apparatus positionedproximate to the sensor 200 during implantation.

Notably, in the embodiment shown in FIG. 4B, the local receiver 400lacks a full graphical display device (such as the graphical displaydevice 440 shown in FIG. 4A). Exclusion of the foregoing graphicaldisplay allows for overall reduced dimensions of the local receiverapparatus 400 making it suitably sized for wear or implantation (such asthe exemplary wearable and implantable local receivers discussed supraand described in U.S. patent application Ser. No. 15/368,436 filed Dec.2, 2016 and previously incorporated herein). Rather, the data from thelocal receiver apparatus 400 is displayed at a full graphical displaydevice 640 associated with the parent platform 700. In some embodiments,the local receiver 400 includes a reduced or limited graphical display(i.e., small graphical display) as one of the output device(s) 410. Forexample, a wrist wearable local receiver can include a small LCD, oreven a capacitive touch screen for sending alerts and/or otherinformation to the user as well as receiving input from the user.

Additional configurations and functionality of the various receiverapparatus are described in U.S. patent application Ser. No. 15/368,436filed Dec. 2, 2016 and previously incorporated herein.

Operational Methods—

Referring now to FIGS. 5-6, exemplary embodiments of the methods ofoperating the analyte sensing system (e.g., a system including either orboth of the local receiver apparatus 400 and the receiver and processorapparatus 450) are described in detail.

FIG. 5 is a logical flow diagram depicting an exemplary embodiment of ageneralized method 500 for operation of the sensor system according tothe present disclosure. As shown in FIG. 5, the method 500 includesfirst enabling and implanting the sensor 200 (or others) per step 502.In the case of the implantable sensor of FIG. 2, the sensor is enabled,implanted in the host (such as via the procedures described in U.S.patent application Ser. No. 14/982,346 filed Dec. 29, 2015 previouslyincorporated herein), and tested as part of step 502.

Next, the receiver apparatus 400, 450 (e.g., any of those of FIGS. 4-4Aherein) is enabled, and maintained within communications range of thesensor apparatus, per step 504. In one variant, the exemplary embodimentof the sensor apparatus 200 uses a 433 MHz narrowband RF transmitter(such frequency having good signal transmission characteristics throughhuman tissue), and hence has a communications range, dependent ontransmission power, of at least several feet. Hence, in oneimplementation of the method step 504, the host/user merely needs tokeep the receiver 400, 450 within arm's reach, or somewhere on theirbody personally. As discussed infra, however, certain embodiments of thedisclosure may implement the “machine learning” aspects indigenously onthe implanted sensor apparatus 200 itself, thereby effectively obviatingthe need for communication with the external receiver 400, 450, at leastfor functions relating to systemic or other error modeling andcorrection.

Subsequent to enablement and implantation of the sensor (and enablementof the receiver), the sensor system is operated in an initial “trainingmode” (step 506, and described below in greater detail with respect toFIGS. 5A-5C), wherein the detector elements of the sensor 200 areoperational and producing signals, yet the data are not output to theuser or other entity, but rather used for “off line” analysis and errormodel generation.

Data collected and/or received during the training mode operation arethen used to generate and store an operational model (such as e.g., auser-specific operational model) (step 508, and described below ingreater detail with respect to FIGS. 5D-5E).

Next, at step 510, after the model is generated, the sensor system isoperated in a detection mode (i.e., a mode whereby data collected fromthe user is corrected as needed, and output for use by the user or otherentity such as a caregiver), based on the operational model.

In some embodiments, operation of the sensor system utilizing theinitial operational model is continued until explant of the sensor.Optionally, per step 512, the system can determine that one or morecriteria for operation of the system in a subsequent training mode(i.e., “re-training”) are met (described in greater detail below),and/or the system can receive a selection from a user or a medicalprofessional/caregiver for re-training. If such a determination orselection is made, the sensor system returns to step 506 for a repeatedoperation in the training mode.

It is also appreciated that while the generalized methodology set forthabove with respect to FIG. 5 utilizes implant of the sensor 200 as aprecondition for training of the machine learning algorithms (so as toostensibly provide the best training environment for that particularsensor/user combination), this may not always be a requirement. Forexample, the present disclosure contemplates conditions where the sensor200 may be “pre-trained” prior to implantation, such as based on datapreviously acquired for that same individual (e.g., as part of a priortraining session and/or prior sensor implantation), or even data derivedfrom one or more similarly situated individuals (e.g., family member,similar physiologic characteristics, similar disease expression, etc.).In such cases, the sensor 200 to be implanted in the individual may forinstance be pre-programmed with data representative of a prioroperational model using wireless or other data communication with thesensor 200 (such as via its 433 MHz or Bluetooth wireless interfacedescribed supra) prior to implantation, such that the model (data) isstored and accessible immediately upon activation of the sensor 200 invivo.

It is further appreciated that the training of the sensor, and/orapplication of the derived model (per step 508 of FIG. 5) may be delayedor “phased in” over time. For instance, in one contemplated scenario,the machine learning logic may be programmed to collect data andgenerate several operational models, including further analysis of themodels with respect to one another (and/or other criteria or models,such as those based on purely theoretical or certain a prioriassumptions). In one such implementation, two or more successive modelsare generated via sensor data collected after implantation, andevaluated against one another for factors such as inter-modelconsistency, and/or rates of change of various attributes of the model(i.e., loosely correlated to an operational “shelf life” of themodel(s)).

Similarly, different paradigms for generation of the models can betested against one another, such as where for example a first modelaccounting for N factors or systemic error sources is compared against asecond model accounting for N-x factors or sources, the latterostensibly requiring less processing overhead and/or other resources. Ineffect, there may be diminishing returns to increasingly sophisticatedmodeling approaches, at the cost of additional required sensor inputs,processing, power consumption within the sensor 200, etc., especiallywhen the incremental improvement afforded by the model is within aprescribed allowable error band or tolerance of the system (e.g., whenthe more complex model generates an improvement in measured bloodglucose level accuracy of 0.1 mg/dl, but the system display, datastorage, or other requisite accuracy is only 1 mg/dl).

Yet further, the present disclosure contemplates use of two or moremodels collectively, whether in parallel or in sequence (or based oncontext or events, such as may be detected by one or more ancillarysensors of the type described supra; e.g., pressure, temperature,acceleration, conductivity, pH, oxygen level, blood flow, electricalimpedance, and others). For example, in one such scenario, thecorrections or other output generated through application of a givenmodel to operational data may be averaged or otherwise mathematically orstatistically combined, or weighted, with similar outputs or correctionsgenerated from other heterogeneous models, so as to avoid any particularmodel skewing the correction unduly. Likewise, certain models may bebest suited or perform best when in a prescribed context or operationalsetting, and hence the weighting of that model (or even use or non-useof the model in its entirety) may be algorithmically adjusted based one.g., sensor data input(s). As a simple illustration, consider a userwith implanted sensor 200 who is ambulatory (as determined by e.g.,accelerometer data resident on the sensor 200 or external receiver 400,450, and/or yet other sensors such as body temperature). Certainsystemic error sources may be more applicable or present themselves to agreater degree in an ambulatory vs. non-ambulatory state, and hencemodels adapted to such error sources would ostensibly perform better inthe ambulatory state as compared to others not so adapted. Hence, upondetection of ambulation, the computerized logic may select (or at leastmore heavily weight) such ambulation-specific models for application tothe generated operational sensor data.

Training Mode Operation

Turning now to FIG. 5A, a logical flow diagram of an exemplaryembodiment of a method 514 for operation of the sensor system in thetraining mode (step 506 of FIG. 5) is shown and described.

First, at step 516, a command is received to operate the sensor systemin the training mode. In one example, after enablement and implantationof the sensor, the user, a medical professional or caregiver enters aselection for operating the sensor system in the training mode via agraphical user interface (GUI) displayed on a display device associatedwith one or both of the receiver 400, 450 and/or the parent platform600, such as touch-screen icon selection corresponding to a“calibration” or “learning” function or the like, which causesgeneration and transmission of a wireless data command to the sensor200. In an alternate example, the sensor system can be automaticallyconfigured to operate in the training mode after implantation e.g., byperforming an automatic “boot-up” procedure, such as based on pre-storedfirmware in e.g., ROM. In other words, once the sensor is enabled andimplanted, and paired (wirelessly) with the receiver 400, 450, thesensor system can automatically enter training mode operation.

In yet another alternate example, the sensor system can bepre-programmed to automatically operate in the training mode afterimplantation each time that it receives (either based on a user inputinto the receiver 400, 450 or via direct transmission from a referencemeter associated with the user and the sensor system) a new referenceanalyte value.

In any of the above examples, the command to initiate training modeoperation (via e.g., a received wireless command or automaticinitiation) can be optionally delayed. In some cases, initiation of thetraining mode can be set to occur after expiration of a delay period(e.g., a day, a week, a month, etc.). Such a delay period can, dependingon the desired functionality, be selected by the user or medicalprofessional, or alternatively the delay period can be pre-programmed.Provision of the delay period can allow the tissue surrounding theimplanted to heal and/or adjust to the presence of the sensor prior tocollecting “training” data from the implanted sensor (thereby making thephysiologic and chemical environment surrounding the implanted sensor200 ostensibly more stable, including blood vessel perfusion in theimmediate locality). Note that this delay is to be contrasted with thatdescribed previously; i.e., the latter referencing application of themodel(s) to operational data.

After the training mode is initialized, a notification is generated andtransmitted to the GUI requesting input of external blood analytereference data (BA_(ref)) per step 518. For example, during trainingmode operation, the sensor system can periodically transmitnotifications to a user to enter a manual blood analyte reading such ase.g., a blood glucose level determined via the aforementioned“fingersticking” method and/or laboratory-type analyzers (e.g., YSIanalyzers). For example, notifications may be sent to the user hourly,every two hours, every three hours, daily, weekly, or according to otherdesired notification schedules.

In response to receipt of the notification, the user obtains and inputsBA_(ref) data (such as e.g., entering data via the GUI) which isreceived by the sensor system per step 520. The BA_(ref) data eitherinclude a time-stamp generated by an external digital blood analytemeasurement device or are time-stamped when received by the sensorsystem. It is noted in passing that in some cases the internal timedomains maintained by physically separate devices are not perfectlyaligned, and hence a time stamp applied to data transmitted from adevice before transmission (e.g., based on collection of the data atactual time t) is different than or misaligned with a time stamp appliedby another device to data collected at that same (actual) time t. Hence,the two time stamps indicate different values, even though both actuallycollected at time t. Accordingly, the present disclosure contemplatesusing a single, unified time domain (e.g., that of the sensor apparatus200, or the receiver 400, or even the parent platform 600), forconsistency, such as where all data is time-stamped with valuesassociated with the unified domain. It will be appreciated that thetime-stamping in such implementations, while conducted based on theunified domain, need not be performed by the device maintaining theunified domain (clock). For example, in one variant, the parent platform600 periodically transmits clock signals indicative of time in itsunified domain (referenced to a known standard or event) to the receiverapparatus 400 and/or sensor apparatus 200, the receiving devices usingthis data to periodically align their own clock domains as needed. Otherschemes for maintaining unified time-stamp data between the various datasets and devices will be appreciated by those of ordinary skill giventhe present disclosure.

In an alternative example, a user can manually enter a time at which theBA_(ref) data were collected. In another alternative example, theBA_(ref) data can be digitally uploaded to the sensor system withoutrequiring a user to manually input the BA_(ref) reading.

It is also appreciated that user notification and/or input may beobviated in favor of direct communication between the sensor system andthe source of BA_(ref), such as where the sensor system generates andtransmits a datagram to an API (application programming interface) ofthe reference data source, requesting the reference data. Upon receivingthe datagram, the reference data source generates and transmits aresponsive datagram containing the requested reference data and anyother appropriate data such as temporal reference, source ID, CRC orother error correction data, etc. The user may also be givenconfirmatory capability via the GUI if desired (e.g., notification tothe user via GUI display that the source has sent a BA_(ref) value tothe sensor 200, and requesting assent by the user via the GUI or otherinput device of the receiver 400, 450 to enter and utilize the value).Alternatively, the reference data source may initiate the datatransmission activity, when e.g., new reference data have been generatedand are available for transmission to the sensor system.

Contemporaneous with the receipt of BA_(ref) data, the sensor systemcollects and calculates a measured blood analyte level reading(BA_(cal)) per step 520.

Methods for collection and calculation of blood analyte level duringtraining mode operation of the sensor system are discussed withreference to FIGS. 5B and 5C. Specifically, an exemplary embodiment of amethod 522 of operating the implanted sensor 200 with the local receiverapparatus 400 and the parent platform 600 and/or the receiver andprocessor apparatus 450 for collection and calculation of training modeBA_(cal) data, as well as an exemplary method 529 of data processing andoutput during training mode operation are described in detail infra.

Specifically, as shown in FIG. 5B, the enabled sensor 200 communicatesdata wirelessly to the receiver apparatus 400, 450, such as on aperiodic, event-driven, continuous, or other basis per step 523 of themethod 522. Note that the transmission and reception frequencies orschedule need not necessarily coincide completely. For instance, thetransmitter of the sensor apparatus 200 may transmit according to aprescribed periodicity or frequency, while the receiver 400, 450 mayutilize a less frequent sampling of the transmissions, or thetransmissions may be buffered or queued for opportunistic transmission(and/or processing by the receiver 400, 450). Similarly, a polling orsimilar approach may be used, such as where the receiver 400, 450 pollsthe sensor 200 when it is ready to receive the data, which may beperiodic or aperiodic in nature.

Per step 525, the received sensor data are processed to calculate bloodanalyte level, and any related parameters or data derived therefrom.Such processing may occur when the data are received, or collectively inone or more aggregations or batches of data (e.g., sensor data collectedor received over a prescribed time period, number of iterations,representative of a prescribed duration of in vivo operation, or other).

Optionally, per step 527, the calculated blood analyte level (e.g.,glucose concentration in e.g., mg/dL or mmol/L) is output to the user ina cognizable form, such as visually, via haptic apparatus, audibly,and/or yet other means, as described elsewhere herein. Similarly, otherinformation (such as, e.g., trend of the blood glucose level, ROC,and/or alert notifications discussed in detail infra) may be output fromthe receiver 400, 450 via the same or different cognizable medium. Itwill be appreciated that output of blood analyte level may also bewithheld or suspended during training mode operation of the sensorsystem, so as to avoid potentially erroneous values being perceived bythe user before model generation and application are completed.

With use of the local receiver 400, the method 522 further may includedetermining whether the parent platform 600 (e.g., the user's morefully-functioned tablet, smartphone, etc.) is “communicative” with thelocal receiver 400 (per step 531), so as to enable the parent platformto utilize its functionality in supply and/or processing of the obtaineddata. When communications between the local receiver 400 and the parentplatform 600 are enabled (per step 535), the local receiver and parentplatform handshake (e.g., pair according to a Bluetooth pairing protocoland/or an Internet of Things (IoT) protocol, with the local receiver asthe slave, and the parent as the master).

It will be appreciated that while the foregoing scenario contemplatesuse of a local receiver 400 to communicate with the parent platform 600,the present disclosure also contemplates, inter alia, use of directcommunication between the sensor apparatus 200 and the parent platform600, such as via wireless (RF) communications. In one suchimplementation, the sensor apparatus 200 includes a Bluetooth wirelessinterface (e.g., BLE variant) which operates at 2.4 GHz and which hasbeen demonstrated by the Assignee hereof to penetrate human tissue withsufficient efficacy so as to maintain a wireless communication channelbetween e.g., the implanted sensor apparatus 200 and the comparablyBluetooth-equipped parent platform 600, the latter further including anapplication program or firmware configured to extract data (whether rawor pre-processed on-board the sensor apparatus 200) from one or moremessages wirelessly transmitted from the sensor 200. Additional detailson one exemplary implementation of the sensor-to-parent platforminterface are described in co-pending U.S. application Ser. No.15/368,436 filed Dec. 2, 2016 and entitled “Analyte Sensor ReceiverApparatus and Methods”, previously incorporated herein.

At step 537, processed and/or raw data from the local receiver 400 aretransmitted to the parent platform 600. Per step 539, the receiver(s)receive the configuration and/or calibration data (as applicable fromthe parent platform 600 in an example where a local receiver 400 isutilized), e.g., such as “fingerstick” or blood glucose monitor (BGM)values entered by the user via the GUI. Alternatively, in an examplewhere a receiver and processor apparatus 450 is utilized, a user or amedical professional can enter configuration and/or calibrationinformation via a GUI displayed at the apparatus 450.

Per step 541, the configuration of the receiver (e.g., the alarm settingvalues, alert logic or hierarchy such as “haptic then visual thenaudible”, etc.) is also optionally updated as needed. Similar to theoptional withholding or suspension of output of blood analyte levelduring training mode operation of the sensor system, receipt ofconfiguration updates may be optionally suspended or withheld during thetraining mode and later updated when the receiver initiates detectionmode operation.

Alternatively, if the parent platform is not “communicative” (e.g.,outside range, busy, preempted, etc.) per step 531 of the method,operation of the local receiver 400 is continued (i.e., periodic orcontinuous receipt and processing of sensor data).

FIG. 5C is a logical flow diagram illustrating one exemplaryimplementation of the sensor data processing and output methodology 529for the local receiver 400 and the parent platform 600 (or the receiverand processor apparatus 450) during training mode operation according tothe method 522 of FIG. 5B. As shown, the method 529 in one embodimentincludes first receiving the wireless data transmissions from the(implanted) sensor 200 per step 545. Next, per step 547, the receivedwireless signals are processed, and the processed data stored (step549). Exemplary implementations of sensor data receipt anddemodulation/unscrambling methodology for the receivers 400, 450 aredescribed in U.S. patent application Ser. No. 15/368,436 previouslyincorporated herein.

Next, the calculated blood analyte level (BA_(cal)) is determined perstep 551. Optionally, one or more random noise signal filters (such ase.g., finite impulse response (FIR), infinite impulse response (IIF),Kalman, Bayesian, and/or other signal processing filters) can be appliedto the BA_(cal) reading to correct for error due to random noise (i.e.,“e” defined supra) per step 553. As a brief aside, as will beappreciated by artisans of ordinary skill in the signal processing arts,typical “white” noise or “random” noise is characterized by a constantpower spectral density. Colored noise spectra may have non-constantpower spectral density; e.g., red tinted noise has less attenuation atlonger wavelengths (lower frequencies), whereas blue tinted noise hasless attenuation at shorter wavelengths (higher frequencies). Commontechniques for removing the effects of random noise include withoutlimitation e.g., time based averaging, statistical sampling, spectrallyweighted averaging, and/or any number of other weighted filteringtechniques.

Further, other parameters of interest if any (such as real-time trendand/or rate of change) are calculated per step 555.

Returning to FIG. 5A, per step 524, in addition to receiving theBA_(ref) data and collecting/calculating the BA_(cal) data, the sensorsystem can optionally collect and/or receive other data. In oneexemplary implementation, the system can collect data (hereinafter“OS_(cal)” data) received from one or more other sensors (such as e.g.,internal sensors 232 on the implanted sensor 200, external sensors 432such as on the receiver or parent platform, or other additional sensorsassociated with the blood analyte detection system). For example, theone or more internal sensors 232 associated with the implanted sensor200 (or similar sensors implanted proximate to the sensor 200) cancollect/calculate internal OS_(cal) data such as e.g., internal bodytemperature in the region of the implanted sensor, pulse rate of theuser, motion and/or orientation data, pressure, pH, local bloodflow/tissue perfusion, electrical impedance of the sensor/tissueinterface, blood analyte concentration of other non-target analytes(e.g., oxygen), and/or other internal data. In another example, the oneor more external sensors 432 associated with the receiver 400, 450 cancollect external OS_(cal) data such as e.g., external body temperature,pulse rate of the user, blood pressure, motion and/or orientation data,and/or other external data, or even pre-processed “state” or othercontext data; e.g., as to what activity or state the user is currentlyengaged in (such as ambulatory, sleeping, exercising, eating, etc., soin effect the computerized modeling logic does not have to deduce orderive this information from raw sensor data alone). In another example,the OS_(cal) data can include information that the system calculatesusing stored data, and may comprise, e.g., the length of time that thesensor has been in operation, the rate of change of sensor signals, etc.

Additionally or alternatively, a user or medical practitioner/caregivercan manually enter other external data such as e.g., body temperature,pulse rate, blood pressure, indicator of exercise, an indicator ofintake of medication, an indicator of resting state (e.g., sleep), anindicator of active state (e.g., exercise), an indicator of ingestion offood (e.g., slow-acting carbohydrates, fast-acting carbohydrates, etc.),and/or other manually entered data, such as via a user interface and anapplication layer program operative to run on the receiver 400, 450, orparent platform 600 (depending on how each is configured). It will beappreciated that manually entered data can be used alone or incombination with data collected via the internal sensors 232 and/or theexternal sensors 432.

In another implementation, the other data can comprise both internalOS_(cal) data and external OS_(cal) data (and/or manually enteredexternal data). In one such variant, the internal sensor data aregenerated only periodically, such as during several discrete periodsduring training phase operation to ensure signal stability, yet minimizeelectrical power consumption with the sensor 200 so as to, inter alia,enhance battery life. In another variant, the external OS_(cal) data canbe calibrated to the internal OS_(cal) data during the training modeoperation, such as where internal temperature is registered (by theinternal temperature sensor of the analyte sensor 200, or a separatelyimplanted internal sensor) as a first value that is higher than say anexternally-sensed temperature produced by a skin temperature sensor onthe local receiver 400, thereby requiring application of an offset orcalibration factor for data generated by the external sensor to reflectinternal body temperature. Thus, in subsequent detection mode operationof the sensor system, the external sensors (e.g., sensors 432 on thereceiver) can be utilized, and the internal sensors can be substantially“turned off,” thereby decreasing power and processing demands on theimplanted sensor 200 (or the other sensors implanted proximate to thesensor 200 if used).

In yet another variant, both the external OS_(cal) data and the internalOS_(cal) data are collected and utilized during the training modeoperation and the detection mode operation to improve accuracy via e.g.,collating data from multiple sources. In still other variants, externaland internal OS_(cal) data can be dynamically selected for use duringdetection mode operation based on data analyses carried out during theoperational model generation (discussed supra).

In each of the above implementations, the other data (i.e., the OS_(cal)data and/or manually entered data) are optionally time stamped such thatthey can later be temporally correlated with the BA_(ref) data and theBA_(cal) data during data processing.

Per step 526 of FIG. 5A, the data collected and received at steps520-524 are stored on a storage device associated with the sensor 200,the receiver 400, 450, the parent platform 600, and/or another storagedevice in data communication with the sensor system. For example, thedata can be stored at one or more of the mass storage 420 associatedwith the receiver 400, 450, the storage 220 associated with the sensor200, a storage device associated with the parent platform 600 (notshown), or a network (“cloud”) storage device accessible via datacommunication with the network 700. Storage is effected via thesoftware/firmware operative to run on the calculating or receivingplatform. For example, in one configuration, the collected data arecalculated on-board the sensor 200 using its internal computerized logicalone, and the resulting data stored locally onboard the sensor 200. Inanother configuration, data calculation is offloaded to the externalreceiver 400, 450 or even parent platform via the wireless interface ofthe sensor, and the processed data returned to the sensor 200 for localstorage. In another configuration, the data calculation is offloaded tothe external receiver 400, 450 or parent platform via the wirelessinterface of the sensor, and the processed data stored external to theuser (i.e., in the receiver 400, 450 or parent or cloud), and a wirelessdatagram sent to the sensor apparatus 200 indicating to the latter thatthe values have been calculated, and are accessible at prescribed datastorage locations, or via API calls.

Receipt, collection, and storage of data are continued until a thresholdof stored data or other criterion is met. Specifically, in theembodiment of method 514, it is determined whether a statisticallyrelevant amount of data has been stored at decision block 528. In oneexemplary implementation, the “training mode” is employed for apre-determined amount of time (e.g., one day, one week, two weeks,etc.). In the foregoing implementation, the threshold for datacollection is the pre-determined amount of time for the duration of thetraining mode operation; therefore, the determination of whether thethreshold for data collection has been met includes determining if atime elapsed since the initiation of the training mode is greater thanthe pre-determined amount of time, such as via a clock function residenton the local receiver logic. This threshold can be made irrespective ofactual data collected, or coupled with a prescribed threshold of datacollection volume (described infra).

In another implementation, the “training mode” is implemented until apre-determined number of data points (i.e., a pre-determined amount ofdata having corresponding time points) are collected. In thisimplementation, the threshold for data collection is the pre-determinednumber of data points; and therefore, the determination of whether thethreshold for data collection has been met includes determining if anumber of collected data points is greater than the pre-determinednumber of data points (which may be e.g., on a numerical basis such asan integer number, on an aggregated data size/storage value such as N kbor Mb, on a storage address basis such as a number of row/columnaddresses in a memory array, or yet other). It will be appreciated thatother threshold criteria and/or a combination of threshold criteria maybe utilized to determine whether the sensor system has collectedsufficient “training mode” data. For instance, the data collection maybe controlled based on a subsequent processing of collected data, suchas where a prescribed first amount of data are obtained, and subsequentsteps of the methodology herein (i.e., model processing/generation) areperformed to determine if satisfactory results can be obtained, such asbased on statistical criteria. In effect, a trial run on analysis andmodel generation may be performed using a given amount of collecteddata, so as to determine statistical or other sufficiency of the datawith respect to generation of a useful model. Depending on the modelchosen for application during the operational phase or mode (which mayin fact be multiple models applied in series or tandem), certain datasets may or may not be sufficient for model generation and applicationin terms of their size, diversity, etc. Hence, by performing “lookahead” processing (including in an iterative fashion; i.e., wherein afirst data set is collected, evaluated, and second heterogeneous or moreexpansive data set is subsequently collected and evaluated), the datacollection threshold may be dynamically specified, as opposed to apredetermined value which, while conservative, may cause undue delay andutilization of sensor processing resources (and hence powerconsumption).

Per method 514, if the data collection threshold or criterion has notyet been met at decision block 528, data collection is continued.Alternatively, if the threshold or criterion is met, the training modeoperation of the sensor system is completed, and the collected andreceived data are subsequently analyzed and processed for operationalmodel generation as described elsewhere herein.

Although not specifically depicted in FIG. 5A, it will be appreciatedthat the training mode operation can additionally include a “manualoverride” or similar function selectable by a user and/or a medicalprofessional. In one example, the manual override function allows themethod 514 to stop prior to meeting the data collectionthreshold/criterion, and proceed to the operational model generation. Inanother example, the manual override function allows the method 514 tocontinue (i.e., allows collection of “training data” to continue) afterthe data collection threshold/criterion is met, prior to operationalmodel generation, so as to permit enrichment of the collected data set,or for other reasons (e.g., to ensure that readings are taken indifferent ambulatory or other user contexts such that the data arerepresentative in such regards).

Operational Model Generation

Referring now to FIGS. 5D-5E, exemplary methodologies for modelparameter identification and operational model generation are describedin detail.

As shown in FIG. 5D, the method of model parameter identification 580includes first identifying a set of available model parameters per step582. This set may be identified for example based on the availablesensors and/or data accessible in a given hardware/software environmentwithin which the sensor apparatus 200 will be used. For example, theaccessible sensor/data set may be as little as (i) the blood analytesensor(s) on the sensor apparatus 200, and (ii) external blood analyte(e.g., BG) reference data, such as from a fingerstick calibrationdevice. More fully featured/instrumented applications may include moresensors and data sources. In the exemplary context of blood glucosemeasurement, some of the likely candidate parameters include: (i)reference background pO2 (O₂ partial pressure) measured by the CGMsensor; (ii) electrode(s) current measured by the CGM sensor; (ii)rate-of-change of electrode(s) current measured by the CGM sensor; (iv)temperature measured by a temperature sensor (e.g. a thermistor)embedded in the CGM sensor or separate therefrom; (v) accelerationsmeasured by an accelerometer embedded in or external to the CGM; (v)pressure (e.g., via indigenous piezoelectric or other sensor on theimplant 200), (vi) pH, and (vii) “state” variable inputs such asuser-input data regarding their activities, ambulatory state, itemseaten and times, and the like.

Next, per step 584, the candidate model parameters identified in step582 are evaluated for selection. In one embodiment, the candidateparameters are evaluated using analytical techniques structured toidentify relative parameter importance. For example, once candidateparameters and a particular machine learning algorithm (including e.g.,Decision Tree, Random Forest, etc.) are defined, those parametersdemonstrating utility in reducing a specified error measure (e.g. MARD,MAD, outlier prevalence, etc.) in a training data set are selected bymeans of a “feature selection” technique. For example, when a RandomForest algorithm is trained using the model parameters andreference-derived BG_(error), an “out-of-bag” or other predictor(parameter) importance can be evaluated, such as by permuting the inputparameter values. See e.g., Out-of-Bag Estimation, L. Brieman, et al,University of California at Berkley(https://www.stat.berkeley.edu/˜breiman/OOBestimation.pdf), incorporatedherein by reference in its entirety, as one exemplary approach. In suchan analysis, the parameters with higher importance metrics tend tobetter predict the output variable, BG_(error).

Lastly, per step 586, a final list of parameters can then be selected,such as for example based on a pre-defined threshold of predictorimportance. Alternatively, a simple criterion to select a prescribednumber (e.g., top ‘n’) of predictors can be employed.

It will be appreciated that the parameter identification process may beconducted algorithmically (e.g., by an application computer program orother software based on provided data sets, heuristically by a human, orcombinations thereof. Moreover, if the relevant model parameters areknown a priori, such model identification methodology 580 may becompletely obviated.

Turning now to FIG. 5E, an exemplary embodiment of a method 530 for dataanalysis and generation of an operational model (e.g., a user-specificoperational model) is shown and described.

Per step 532, blood analyte detection error data (BA_(error) data) isfirst calculated for the BA_(cal) data, based on the received BA_(ref)data, at each corresponding time point. For example, the BA_(error) datacan be calculated as the mean absolute relative difference (MARD)between the calibrated analyte sensor output (BA_(cal) data) and theexternal analyte reference data (BA_(ref) data), as set forth in Eqn.(2) below:

$\begin{matrix}{{M\; A\; R\; D} = \frac{\sum\limits_{1}^{N}{{{BA}_{cal} - {BA}_{ref}}}}{N}} & (2)\end{matrix}$

where N is the number of matched pairs of sensor readings and referencesamples.

Alternatively (or in tandem), the BA_(error) data can be calculated asor by the frequency of outliers in the comparison of the BA_(cal) dataand the BA_(ref) data, such as using the frequency of occurrences where

|BA _(cal) −BA _(ref) |>A*BA _(ref)  (3)

where A is a threshold level that may have a value of, e.g., 0.2 or 0.3,so that outliers are determined to be instances where the sensor outputdiffers from the reference value by more than, respectively, 20% or 30%of the reference value.

Additionally or alternatively, the BA_(error) data can be calculatedutilizing one or more other methods (such as e.g., standard deviation,mean absolute difference, etc.).

After calculation of BA_(error) data, per step 534, one or more “machinelearning” algorithms are selected/identified for modeling the BA_(error)data. In one implementation, a single algorithm is pre-selected (e.g.,an experimentally pre-determined algorithm) for utilization in modelgeneration prior to implantation of the sensor. Differently stated, thesensor system can be pre-programmed to utilize a single desiredalgorithm, such as e.g., an algorithm selected for its particularattributes such as robustness, accuracy, etc. In another implementation,a medical practitioner may select (e.g., prescribe) one of multiplealgorithms for use in a specific patient (i.e., user) prior to or afterimplantation of the sensor, ostensibly based on the desirability of thatalgorithm for use within the particular user based on their particularphysiologic attributes, lifestyle, sensor location, etc. For example, ineach of the foregoing implementations, the desired algorithm or theprescribed algorithm may be selected based on known algorithmcharacteristics (e.g., speed, accuracy, required processing power,robustness to errors, etc.), and/or characteristics of the user (e.g.,known medications or treatments, known lifestyle characteristics, knowndisease characteristics, etc.), including based on prior analysis of thealgorithms prior to implantation such as via computer analysis onvarious test or patient-derived data sets.

An exemplary decision tree 600 (i.e., Decision Tree-based algorithm) isshown in FIG. 6, wherein each end-node predicts a specific error (orsource). The Decision Tree is generated using an algorithm whichrecursively splits a node (parent), containing training data, into twochild nodes (Left and Right) based on a predictor variable, itsthreshold value, and an objective error criterion. The Left nodecomprises all of the training samples from the parent node that havepredictor values less than the threshold whereas the Right nodecomprises all of the training samples from the parent node that havepredictor values greater than or equal to the threshold. The (child)nodes are continued to be split until a termination criterion is met.For example, further splitting of a node can be terminated if the numberof training samples in the node is equal to or smaller than a predefinedthreshold. The nodes that cannot be split further are called leaves(end-nodes). Once a Decision Tree is generated, an error estimationthrough this decision tree requires traversing the tree nodes utilizingbinary decisions based on the respective model parameters and theirthresholds. Once an end-node (also called ‘leaf’) of a tree is reached,the error estimate (e.g., mean value of the error in all of its trainingsamples) associated with the leaf is used for the correction.

In yet another implementation, more than one machine learning algorithm(including e.g., Decision Tree, Random Forest, Naïve Bayesclassification, support vector machines (SVM), Gradient Boosting, andAdaBoost) can be utilized to model the training data during operationalmodel generation, and the algorithm that yields the “best” result can beused in the operational model. For example, the sensor system (orexternal platform such as the receiver 400, 450, or parent 600) can bepre-programmed to analyze the data via e.g., three (3) different machinelearning algorithms, thereby generating at least three sets of data(i.e., at least one set of data output from each algorithm). Each of thesets of data can then be compared or otherwise evaluated againstperformance criteria to identify the “best” algorithm for generation ofthe operational model. In the foregoing example, the “best” algorithmmay be selected based on a desired characteristic such as e.g., speed,accuracy, required processing power, robustness, and/or other desiredfeatures. The initial set of three algorithms in this example may beselected by the aforementioned experimental or other analyticalevaluation, based on the particular attributes of the user in which thesensor 200 is intended to be implanted. For instance, the data vectorsfor a given individual (e.g., height/weight, BMI, race/ethnicity, age,stage of disease progression, etc.) can be evaluated to identify apreviously determined subset of algorithms which are better suited tothose falling within such classes, and their implanted sensor 200preprogrammed with that subset of algorithms, in effect pre-filteringthe algorithms for that individual so that the best algorithm(s) can bemore rapidly converged on during model generation.

Further, in each of the foregoing implementations, the one or moremachine learning algorithms may be differentially applied to selectedportions of the collected data in order to analyze various parameterswhich may or may not be correlated with error occurring at the implantedsensor (i.e., correlated with the BA_(error) data). In a variant whereonly the BA_(cal) data are collected from the implanted sensor duringtraining mode operation (i.e., no external data or OS_(cal) data arereceived/collected), variables or parameters can include the sensorelement(s) of origin (e.g., an identification of one of four sensorelement pairs 206 shown in FIGS. 2-2A), electrode current at one or moreof the sensor elements, rate-of-change (ROC) of electrode current at oneor more of the sensor elements, reference (i.e., background) of oxygenconcentration measured by one or more of the sensor elements, time ofday (e.g., 6 AM, 7AM, 8 AM, etc.), range of time of day (e.g., earlymorning, midday, night, etc.), range of blood analyte concentration(e.g., high range, median range, low range, etc.), age of sensor (i.e.length of time the sensor has been operating), impedance among sensorelements (both within the sensor itself and as measured through tissueadjacent to the sensor), and/or other determinable parameters that canbe extracted from the sensor data.

In another variant where other data (e.g., internal OS_(cal) data,external OS_(cal) data, or other user input data) are received and/orcollected in addition to the BA_(cal) data during training modeoperation, variables or parameters can additionally include temperature,acceleration, orientation, pressure, pulse rate, one or more othernon-target blood analyte concentrations, intake of medication, intake offood, designated resting period of the user, designated active periodthe user, and/or other determinable parameters that can be extractedfrom the other sensor data and/or the user input data such as user stateor context data. Per step 580 (FIG. 5D), a final list of one or moreparameters is selected based on a predictor importance/relevancecriterion.

As a brief aside, machine learning algorithms construct models ofbehavior from a set of sample inputs (here, e.g., blood glucosecalibration data). Such models enable performance of a set of tasks as afunction of previous experience, based on optimizing a performancemetric as a function of the experience. Machine learning is typicallyfurther categorized into supervised, unsupervised and reinforcementbased learning based on the types of input/output generated by thesystem.

So-called “supervised learning” algorithms determine a set of tasks tooptimize outputs from a set of inputs; where a supervising entity (e.g.,a human trainer) has defined the appropriate inputs and outputs.So-called “unsupervised learning” takes a non-curated data set andattempts to interpolate a series of relationships to identify e.g.,inputs and outputs. So-called “reinforcement learning” algorithms areadapted to receive feedback over a plurality of training trials usingdynamically generated input.

Various functions of the apparatus or systems described herein may beimplemented within various ones of the foregoing categories of machinelearning. For example, supervised learning solutions may be useful toquickly adapt the known input BA_(cal) to the expected output BA_(ref).Unsupervised learning may be used to find hidden correlations betweenthe various sensor inputs; for example, unsupervised learning may beable to infer complex interrelationships between e.g., heart rate,oxygenation, and blood glucose which would be otherwise too complex togenerically model, or the bases for which are unknown. Reinforcementtechniques may be used by doctors, or other trained personnel to finetune and or further tailor measurements. Still other applications of theforegoing will be readily appreciated by those of ordinary skill in therelated arts.

The aforementioned machine learning algorithms are purely illustrativeexamples of artificial intelligence algorithms that are configured toadapt to changes in data sets. More generally, artisans of ordinaryskill in the related arts will appreciate that any logic that isconfigured to learn or be trained from a set of initial training data,and subsequently predict or provide decisions for physiologicalparameters (e.g., glucose) may be substituted with equivalent success,given the contents of the present disclosure. For example, anothermachine learning algorithm referred to as Support Vector Machine (SVM)with a linear or non-linear kernel can be utilized to model theBA_(error) as a function of input model parameters. In the case of alinear kernel SVM, BA_(error) is modeled as a linear function of modelparameters by utilizing a training data set and minimizing a pre-definedcost function (J) subject to criteria on residuals and cost functionvariables. As an example, if background pO2 (pO2) and rate-of-change ofbackground pO2 (roc_pO2) are used as model parameters for estimatingBA_(error), a linear SVM model can be generated as:

F(x)=A*pO2+B*roc_pO2+C  (4)

Where F(x) provides an estimate of BA_(error), given the measurement ofpO2 and roc_pO2 from the sensor, and

A, B, C are model parameters generated using a training data setcomprising n training samples, a cost function, and model constraints.Example forms of cost function (J) and model constraints (K) areprovided below as eqns (5) and (6):

$\begin{matrix}{J = {{0.5*\left( {{A*A} + {B*B}} \right)} + {x{\sum_{n = 1}^{N}\left( {\mathcal{E}_{n} + \mathcal{E}_{n}^{*}} \right)}}}} & (5) \\{K = {\bigvee{{- n}\left\{ \begin{matrix}{{{BA_{error}} - \left( {{A*p\; O\; 2} + {B*{roc\_ pO2}} + C} \right)} \leq {\alpha + \mathcal{E}_{n}}} \\{{\left( {{A*{pO}\; 2} + {B*{roc\_ pO2}} + C} \right) - {BA_{error}}} \leq {\alpha + \mathcal{E}_{n}^{*}}} \\{\mathcal{E}_{n} \geq 0} \\{\mathcal{E}_{n}^{*} \geq 0}\end{matrix} \right.}}} & (6)\end{matrix}$

Where α is a predefined residual margin, and ε is a slack variable (softmargin) allowing the model generation to converge.

Per step 540, an operational model is then generated for prediction ofBA_(error) during normal operation of the implanted sensor (i.e.,detection mode operation) based on the one or more selected/identifiedparameters and the determined relationship with BA_(error). The model isstored at one or more of the storage devices discussed supra (step 542)for subsequent use during operation of the sensor system in thedetection mode (step 510 of FIG. 5).

It will also be appreciated that instead of modeling the blood analyteerror (e.g., BG_(error) in the foregoing examples) directly, theapparatus and methods described herein may be adapted to use modelparameters including for instance the “calibrated” CGM-generated bloodglucose values (CG_(cal)), computed by applying a known calibrationtransform to the raw CGM data, to directly estimate a blood glucosevalue (BG_(model)). Therefore, BG_(error) will indirectly be calculatedas BG_(model)−CG_(cal).

Also, in addition to estimating error in CGM-reported blood glucose, themodeling may be performed to estimate the error in the CGM-reportedrate-of-change (ROC) of the blood glucose (e.g., the first derivative ofthe raw data over time), assuming sufficient numbers of reference bloodglucose values collected closely in time are available to enablecalculation of a reference rate-of-change. Hence, the “ROC” error can beestimated as [ROC_(ref)−ROC_(CGM)].

Detection Mode Operation

Methods for collection and calculation of blood analyte level duringdetection mode operation of the sensor system are discussed withreference to FIGS. 5B and 5F. Specifically, an exemplary embodiment of amethod 522 of operating the implanted sensor 200 with the local receiverapparatus 400 and the parent platform 600 and/or the receiver andprocessor apparatus 450 for collection and calculation of detection modeBA_(cal) data, as well as an exemplary method 529 of data processing andoutput during detection mode operation, are now described in detail.

It will be appreciated the method 522 is substantially similar duringdetection mode operation as during training mode operation, and thusmuch of the method described supra for determination of BA_(cal) dataduring the training mode operation is applicable to determination ofBA_(cal) data during detection mode operation. Notably, whereas outputof BA_(cal) data (i.e., output of the blood analyte level) is optionalin the training mode operation, such output is generally a primaryfunction (non-optional) of the sensor system during the detection modeoperation, so as to maintain the user and/or caregiver informed as toblood analyte level, and implement any relevant indication or alertregimes. In some instances (such as e.g., when the receiver is out ofrange of the implanted sensor), blood analyte data (and/or otherinternal data) can be continuously collected at the sensor duringdetection mode operation without (immediate) output of BA_(cal) data.

Additionally, one or more of the data processing steps during thedetection mode deviate from or supplement those in the training modeoperation (e.g., method 529 of FIG. 5C). Specifically, the dataprocessing step of the detection mode operation further includes (atleast) application of the stored operational model on the implantedsensor analyte data (BA_(cal) data).

As discussed supra, FIG. 5F is a logical flow diagram illustrating oneexemplary implementation of the sensor data processing and outputmethodology 561 for the local receiver 400 and the parent platform 600(or the receiver and processor apparatus 450) during detection modeoperation according to the method 522 of FIG. 5B. As depicted in FIG.5F, the method 561 in one embodiment includes first receiving thewireless data transmissions from the (implanted) sensor 200 per step563. Next, per step 565, the received wireless signals are processed,and the processed data stored (step 567). Exemplary implementations ofsensor data receipt and processing, including demodulation/unscrambling,for the receivers 400, 450 are described in U.S. patent application Ser.No. 15/368,436 previously incorporated herein.

Next, calculated blood analyte level (BA_(cal)) is determined per step569. The BA_(cal) data are then processed via application of the storedoperational model on (i) the BA_(cal) data, and (ii) data from the oneor more identified parameters correlated with BA_(error) (such as e.g.,temperature data, motion data, orientation data, pulse rate data, otherblood analyte concentration data, manually entered user data, etc.),thereby generating BA_(cal) data corrected for BA_(error) (i.e.,systemic error from unmodeled user-specific variables) per step 571. Inone implementation (implanted blood glucose sensor), once a new bloodglucose sample is recorded by the system, it will compute all the modelparameters selected and defined in the model parameters identificationprocess using the new BG sample data (and any number of past samplesneeded). Once the model parameters are computed, the machine-learningmodel generated via the user-specific model generation process isapplied to predict the BG_(error). Similarly, CG_(cal) (the “calibrated”CGM BG data) is computed by applying the known calibration transform tothe raw CGM data, and the predicted BG_(error) is subtracted fromCG_(cal) to provide a closer approximation of BG_(ref) (albeit stillcontaining effects due to random noise).

Optionally, one or more random noise signal filters can be applied tothe corrected BA_(cal) reading to additionally correct for error due torandom noise (i.e., “e”) per step 553 (see discussion of random noisesupra).

Other parameters of interest if any (such as real-time trend and/or rateof change) are calculated based on the corrected BA_(cal) data per step573. Optionally, the calculated values from steps 571, 573, 575 are thenconverted per step 577 to a prescribed output format (e.g., a graphicrendering of a numeric value, a graphic display of a trend arrow, asequence of haptic vibrations, etc.) consistent with theselected/configured output modality. The converted values or indicationscan then be output to the user in the appropriate modality/modalitiesper step 579, such as via the GUI.

It will be appreciated that the analyte sensor system may operate indetection mode simultaneously with its operation in training orre-training modes. That is, if a suitable model has already been madeavailable to the sensor system (e.g. by previous training or by factoryprogramming), then model-based error correction can be applied anderror-corrected BA_(cal) reported by the system even while the steps arebeing carried out to develop a new model (training or re-training).After the new model has achieved a sufficient state of readiness, thenthe system may abandon (or modify) the previous model in favor of a newmodel.

Re-training Determination

As depicted in step 512 of FIG. 5, in one exemplary embodiment, themethod of operating the sensor system 500 includes optional“re-training” of the sensor system. The aforementioned “re-training”substantially comprises a subsequent operation of the sensor system inthe training mode after an initial training mode operation. As such,re-training may occur for example: (i) after implantation, and after aninitial in vivo training operation; (ii) after implantation, and afteran initial explanted training operation conducted before the sensor 200is implanted; (iii) after explant, and subsequent re-implantation of thesame or similar sensor 200 in the same individual.

Notably, such re-training can be used, inter alia, to compensate forshort-term or long-term changes or variations in sensor response orsubject physiology; i.e., how the sensor responds to prevailing in vivoand sensor operational conditions it finds itself in at any given pointduring its implanted lifetime. For example, one or more of the detectorpairs of the sensor 200 may become less sensitive or more sensitive orfail over time, and/or the host's physiological responses (including FBRor other such factors) may vary as a function of time. Ancillary sensorson the sensor 200 (e.g., pressure, temperature, etc.) may also fail ortheir response characteristics may change, thereby necessitating theirre-evaluation or removal from the algorithmic modeling process.

Moreover, the coupling or interface of the sensor 200 and the host'stissue may change, including due to mechanical events such as a physicalimpact, strenuous exercise or activity, etc., such that the sensordetector pairs must be “re-acclimated” to the new physical couplingafter movement of the sensor 200 within its implantation pocket withinthe host's tissue. Yet further, new and previously un-modeled (withinthat individual) physiological or non-physiological error sources mayarise over time, or other previously modeled sources (i.e., accountedfor in the model developed after initial training) may wane over time.New algorithms may also be developed, and it may be desired to retro-fitthem into an already implanted device.

As can be appreciated, any number of the above factors or others, maydictate a re-training of the sensor while in vivo. Generally speaking,many if not all of the above sources of possible variation in signalwill manifest themselves in varying degree in the BA_(error) valueultimately identified using the applied operational model, and hence themagnitude and/or rate of change (ROC), and/or number of data outliers(e.g., stability), can be used as a determinant or passive/post hocindicator of change of one or more sensor operational or physiologicalprocesses. However, the present disclosure also contemplates proactiveor advance determination of the change of one or more sensor operationalor physiological processes.

FIG. 5G is a logical flow diagram illustrating one exemplaryimplementation of a method 544 of determining the need for re-trainingof the sensor 200. This methodology can be implemented by the implantedsensor apparatus 200 (i.e., by logic operative thereon), by the localreceiver 400 and the parent platform 600, the receiver and processorapparatus 450, or combinations of the foregoing (depending on how thelogic is distributed within these devices), during detection modeoperation according to the method 500 of FIG. 5.

As depicted in FIG. 5G, while the sensor system is operated in thedetection mode (per methods 522 of FIG. 5A and 559 of FIG. 5F), it canbe determined whether one or more criteria for re-training have beenmet, with any single criterion triggering re-training in the illustratedembodiment.

In the exemplary method 544, it is first determined whether BA_(error)is greater than a pre-determined threshold at decision block 546; i.e.,the magnitude of BA_(error) averaged over a period of time is greaterthan a pre-determined threshold value for BA_(error). In anothervariant, it can additionally or alternatively be determined whether theBA_(error) outlier data include a number of outliers that are greaterthan an outlier threshold (or threshold percentage of the data;e.g., >20 percent are outliers). For example, a pre-determined thresholdfor a daily average BA_(error) is ±15% of respective BA_(cal) valuesand/or a pre-determined BA_(error) outlier data threshold is 30% ofrespective BA_(cal) values. In both variants, if the determinedBA_(error) and/or BA_(error) outlier data are greater than therespective pre-determined threshold(s), a repeated operation of thesensor system in the training mode can be initiated (step 554). In someexamples, a notification is sent to the user to confirm or requestinitiation of a subsequent training mode.

Alternatively, per method 544, if BA_(error) and/or BA_(error) outlierdata are less than the respective pre-determined threshold(s), otherre-training criteria can be determined.

Per decision block 548, it is next determined if a time elapsed sinceinitiation of the detection mode is greater than a pre-determinedthreshold (e.g., a duration of time for operating the sensor system inthe detection mode and hence without training). In one specific example,a pre-determined threshold for a time period for detection modeoperation is one week. Thus, if the sensor system has been operating inthe detection mode for a duration of time greater than theper-determined threshold, a repeated operation of the sensor system inthe training mode is initiated (step 554), so as to keep the errorcorrection capability of the system “fresh” in light of any potentialphysical or physiological changes in the operation of the sensor 200.

Alternatively, if a time elapsed since the initiation of the detectionmode operation is less than the pre-determined threshold, otherre-training criteria can be evaluated.

In the method 544, it is further determined whether a “re-trainingevent” has been detected per decision block 550. If such an event isdetected, a repeated operation of the sensor system in the training modeis initiated (step 554). Alternatively, if no re-training event isdetected, other re-training criteria can be evaluated.

Exemplary re-training events can include one or more of: (i)notification (e.g., via wireless message to/from the sensor apparatusfrom/to the external receiver) or internal determination that the sensorsystem has been recalibrated, (ii) detection of an occurrence of anunusually high temperature (e.g., detection of a temperature greater orless than a pre-determined high/low temperature threshold, respectively,and/or detection of the high/low temperature for a duration of timegreater than a pre-determined threshold); (iii) detection of a physicalimpact to the user (e.g., detection of a pressure and/or accelerationvalue greater than a pre-determined threshold; (iv) detection of anoccurrence of an unusually high or low pulse rate (e.g., detection of apulse rate greater/less than a pre-determined high/low pulse ratethreshold respectively, and/or detection the high/low pulse rate for aduration of time greater than a pre-determined threshold); (v) detectionof a change in electrical impedance among sensor electrodes; (vi)detection of an increase in variance in the outputs among redundant orduplicative detectors, either located in the same sensor housing or inseparate sensors; (vii) detection of change/drift in moving average ofthe direct sensor measurements or derived sensor measurements, e.g.average daily pO2, average weekly pO2, average daily concentration ofglucose, change in daily correlation among different Cg channels whenmultiple detectors/pairs are available, daily correlation amongdifferent O2 channels, daily correlation between Cg and O2 channel, etc.

In some implementations, the re-training events can be selected by thesensor system based on the identified parameters which are correlated toBA_(error) for the specific user. For example, if temperature iscorrelated to BA_(error) while pulse rate is uncorrelated, re-trainingevents can include the occurrence of the foregoing temperature events,while the aforementioned pulse rate events are excluded from the set ofevents that initiate retraining.

Per decision block 552, it is next determined whether a command orselection for re-training has been received. Specifically, a user, amedical professional, and/or a caretaker can input a request forre-training of the sensor system, such as based on known userinformation, or merely as a “soft re-boot” (e.g., to attempt to clearprospectively anomalous behavior by the sensor 200). For example, if auser undergoes a significant lifestyle change (e.g., change in diet orexercise regimen), a change in disease presentation, a physiologicalchange (e.g., onset of a transient illness or diagnosis of a secondarydisease, significant weight gain or weight loss, etc.), a change inmedication, goes on a vacation or other deviation from normal routine,such changes may warrant retraining to ensure that the generated modelis still applicable and optimized. In another example, a user may sensea feeling of being “off” or a sensation of malaise, and may selectivelyinitiate retraining as desired. If a selection for re-training isreceived, a repeated operation of the sensor system in the training modeis initiated (step 554). Alternatively, if no selection for re-trainingis received (in addition to a “NO” for each of the other criteria ofdecision blocks 546-550) operation of the sensor system in the detectionmode is continued according to the methods 552 and 559.

It will be appreciated by those skilled in the art given this disclosurethat the exemplary method 544 is just one possible method fordetermining if re-training criteria are met. In alternateimplementations, the method can include more or fewer decision blocks,and/or the decision blocks can be executed in a different sequence.Other logical constructs may also be used, such as e.g., a “coincidence”requirement where two or three criteria must simultaneously be met inorder to trigger re-training. Moreover, a hierarchy of evaluation may bedetermined and leveraged; i.e., the order and frequency with which thevarious criteria are evaluated may be adjusted, such as where a mostlikely re-training factor/threshold to be exceeded is evaluated first ata first frequency, and other less-likely factors/thresholds evaluated ata reduced frequency.

FIG. 7 illustrates one particular implementation of the foregoingmethodology of correcting for systematic error (BA_(error)=Blood Glucoseerror or BG_(error)) in the reported blood analyte level value(s) ofFIGS. 5-5F, in the context of an implantable oxygen-based bloodcontinuous glucose monitor (CGM) having multiple detectors/pairs, forpurposes of illustration. As shown in FIG. 7, the method 700 includesfirst collecting sample data from the CGM over a time period [t_(i),t_(f)] per step 702. Multiple reference blood glucose samples (BG_(ref))relating to the same time(s) [t_(i), t_(f)] are also collected per step704.

Next, CGM-generated samples (CG_(cal)) matching the BG_(ref) samplesbased on a specified criterion (e.g., time and/or CGM measurementsrate-of-change) are selected to form a set of matched data(D_(BGref,CGref)) step 706.

A corrective regression or analytical scheme (T_(r)) (e.g. DecisionTree, Random Forest, linear regression, etc.) is next defined per step708, and one or more predictors or feature vectors (f_(v)) are derivedfrom CGM sensor data and/or ancillary sensors (e.g., fingerstick meters,thermistors, accelerometers, etc.) per step 710.

Predictor variables (f_(v)) for the set of matched data D_(BGref,CGref)are then computed per step 712. These vectors are used within theregression or other analytical model framework to predict respectivesystematic errors. The corrective regression model (T_(r)) is then“trained” using the computed predictors (f_(v)) and the expected/trueresponse values for blood glucose (BG_(ref)) per step 714.

The trained regression model (T_(r)) is then used in step 716 toestimate (in real-time) the error in CGM-reported blood glucose valuesby processing (then) current new values of the predictor variables(f_(v)), and the estimated error is used in real-time to correct theCGM-reported blood glucose for the effect of such errors (step 718).

Exhibit I hereto contains exemplary computer code implementing one ormore aspects of the foregoing methodologies.

Population-Based Models

In some embodiments, the foregoing training mode operation of the sensorsystem can be carried out in an experimental or analytical setting on apopulation (such as e.g., a statistically significant group of testsubjects) to build multiple “user-type” operational models, which caninter alia, be later applied to other users with similar characteristicsto determine BA_(error). In one such embodiment, user characteristics ofthe test subject(s) are identified, and each of the test subjects isimplanted with a sensor (e.g., pursuant to their normal implantationschedule or needs), and the sensor operated in the training mode(discussed supra). An operational model is then generated for each testsubject (whether via onboard processing logic of the implanted sensor,off-board processing via the receiver 400, 450, the parent platform 600,or cloud-based entity such as a server maintained by a health careadministrator or even the manufacturer of the sensor, or combinations ofthe foregoing), and the operational model correlated to the usercharacteristics, in order to generate one or more population-basedoperational models or “user-type” operational models.

After such model development, characteristics of other users (i.e.,non-test subject users, such as new patients) can be identified, and aspecific population-based operational model can be implemented based onthe identified characteristics within the implanted sensor system,without the need for operation of the implanted sensor in the trainingmode (or rather a confirmatory training process). For example, it may befound that persons of a certain gender, age, race or ethnicity,physiologic profile—which may include the presence or absence of certaingenetic markers, blood constituents (e.g., proteins, antibodies,antigens, etc.), BMI, or other parameter, exhibit certain types ofsystematic or other error sources relative to the BG measurement, with ahigh degree of statistical confidence. This correlation can be used inpicking an operational model for a user falling within such class priorto or in place of user-specific operational models.

Moreover, the efficacy or accuracy of such population-based correlationscan be assessed based on in vivo data obtained from that user. Forexample, the implanted sensor can be used to gather data from thatparticular individual (e.g., according to the methods of FIGS. 5-7above) and development of a user-specific model, which can then becompared to the population-based model to identify variationstherebetween. If the user-specific models developed for numerousindividual users show significant statistical divergence or variationfrom the relevant population-based model(s) selected for that user, thenthe strength of the statistical correlation or confidence in thepopulation-based models is necessarily low, and their structure (e.g.,in terms of errors modeled) and/or selection criteria may need furtherrefinement. In a simple example, assessments of the divergence of theerror corrections or corrected BG values produced by the user-specificmodel could be utilized to de-select a population-based model for aspecific user.

Hence, in one approach (“evaluation mode”), the user-specific (trainingmode derived) model can be run in parallel with the pre-designatedpopulation-based model on the same in vivo user data to generatecorrected BG level outputs for each; these can then be compared to e.g.,an external calibration data source or other “gold standard” for theactual BG level in that user at that time, to assess model performance.

Likewise, the sensor system may be programmed to utilize thepopulation-based model (thereby ostensibly obviating training) until oneor more indicia of divergence are seen; e.g., where the population modelbegins to diverge significantly in magnitude, or at a rate greater thana prescribed value, based on periodic external calibration. At suchpoint, the system (e.g., sensor 200) may automatically invokeimplementation of “training” via the methodologies described above, andreplacement or augmentation of the population-based model with theindigenously developed user-specific model, for subsequent operationwithin that particular user.

In some examples, the group of test subjects are a selected group ofvolunteers. In other examples, the group of test subjects can beexisting users from which data are collected for generation ofpopulation-based models.

One exemplary implementation of a method 800 for generation andapplication of population-based operational models is shown anddescribed in a logical flow diagram depicted in FIG. 8. The method 800generally (ii) includes an analytical or experimental phase 802 forgeneration of the population-based operational model(s), and (ii) autilization phase 804 for application one of the population-basedoperational models during normal (or trial) use of the sensor system.

As illustrated in FIG. 8, the analytical or experimental phase 802begins with collecting (e.g., derived from measurable information) orreceiving (e.g., manually input test subject information) a series ofuser data vectors such as e.g., gender, height, weight, diet, exerciseregimen, disease presentation, medications, blood pressure, active pulserate, resting pulse rate, average body temperature, geographic region ofresidence, etc. from each member in a group of test subjects (step 806).In some examples, the selected user data vectors are combined into aninput vector and/or organized into a matrix of user data vectors.

Per step 808, each of the test subjects is implanted with a sensor 200.After the sensor is implanted and enabled, the sensor system is operatedin a training mode (such as e.g., the training mode operation shown inFIGS. 5-5C, discussed supra) in order to generate an operational modelfor each test subject (step 810). After download of the model data fromthe sensor system (e.g., via wireless transmission from the implantedsensor 200, or the receiver 400, 450), the various operational modelsare then correlated with the respective previously collected and/orreceived user data vectors to identify user characteristics that areassociated with each operational model, thereby generating a set ofpopulation-based operational models (step 812). Such correlation may bestatistical in nature (e.g., according to mean error, standarddeviation/variance, and/or other statistical criteria as determined byalgorithmic analysis by a computerized system), or even heuristic (e.g.,by a human utilizing inductive reasoning or other cognitive tools toidentify patterns in both the models and the data sets).

Subsequently, the experimentally determined population-based operationalmodels can be utilized for operation of an implanted sensor system withnon-test subject users (phase 804, discussed supra). Specifically, inthe exemplary method 800, user data vectors are collected and/orreceived from a user (i.e., a non-test subject user, such as a newpatient), and then compared to the test subject data vectors per step814 that are correlated with the particular population-based model(s).It will be appreciated that the series of user data vectors for thenon-test subject user are substantially similar to those collectedand/or received from the test subjects during the experimental phase 802such that a “best” match comparison can be performed. Further, in someexamples, the selected user data vectors may be combined into an inputvector and/or organized into a matrix of user data vectors in asubstantially similar manner as is carried out for the test subject userdata vectors in order to carry out the comparison.

Per step 816, a correlated population-based operational model isidentified based at least on the input vectors for the user. The user isimplanted with the sensor and the sensor system is enabled per step 818.The sensor system is then operated in the detection mode (such as e.g.,the training mode operation shown in FIGS. 5A-5C, discussed supra)utilizing the population-based operational model to correct forBA_(error) (step 820). Thus, in this embodiment, the sensor system isoperated in the detection mode (with application of the experimentallydetermined population-based operational model) directly afterimplantation without prior or initial operation in a training mode.

Although not specifically shown in method 800 of FIG. 8, in alternateembodiments, the method can further include determining if one or morere-training criteria are met (substantially similar to method 544 shownin FIG. 5G). In this embodiment, the population-based operational modelcan be updated or replaced as necessary or as desired by the user.Re-training criteria can include those determined from populationcharacteristics (e.g. retraining at time intervals found to provideoptimum performance in the population) or other thresholds and variablesspecific to the individual user, as described supra.

It will be recognized that while certain embodiments of the presentdisclosure are described in terms of a specific sequence of steps of amethod, these descriptions are only illustrative of the broader methodsdescribed herein, and may be modified as required by the particularapplication. Certain steps may be rendered unnecessary or optional undercertain circumstances. Additionally, certain steps or functionality maybe added to the disclosed embodiments, or the order of performance oftwo or more steps permuted. All such variations are considered to beencompassed within the disclosure and claimed herein.

While the above detailed description has shown, described, and pointedout novel features as applied to various embodiments, it will beunderstood that various omissions, substitutions, and changes in theform and details of the device or process illustrated may be made bythose skilled in the art without departing from principles describedherein. The foregoing description is of the best mode presentlycontemplated. This description is in no way meant to be limiting, butrather should be taken as illustrative of the general principlesdescribed herein. The scope of the disclosure should be determined withreference to the claims.

EXHIBIT I Exemplary Computer Code © 2017 GlySens, Inc. All rightsreserved %% Function performing feature (modeling parameters) selection% Apply calibration to sensor measurements and return % calculated Cgsubject to systematic errors and modeling parameters[Cg_preprocessed_cal, featureSet1, featureSet2, featureSet3] =computeCgUsingCalCoeffs(sensorRawIworks_cal, O2_Calibration_coeffs,Cg_cal_coeffs); feature_composite = [featureSet1, featureSet2,featureSet3]; Cg_error = BloodGlucoseReference.samples -Cg_preprocessed_cal; numOfFeatures = size(feature_composite,2); % numberof modeling parameters % linear correlation between parameters and theBG error correlationIndex = zeros(numOfFeatures,1); for i = 1 :numOfFeatures  correlationBwFeatureAndError = corrcoef(Cg_error,feature_composite(:,i));  correlationIndex(i,1) =abs(correlationBwFeatureAndError(1,2)); end importantFeatureIndices =find(correlationIndex > 0.4); % Selected featuresif(length(importantFeatureIndices) < 5)  [~, idxs] =sort(correlationIndex, ′descend′);  importantFeatureIndices = idxs(1:5);end

1.-20. (canceled)
 21. A method of monitoring a blood analyte levelwithin a living being using a blood analyte sensing apparatus, themethod comprising: calibrating the blood analyte sensing apparatus usingone or more predetermined calibration models; operating the calibratedblood analyte sensing apparatus in a training mode; based at least inpart on the operating in the training mode, generating an errorcorrection operational model; and subsequent to generating the errorcorrection operational model, operating the blood analyte sensingapparatus in a detection mode, the operating in the detection modeincluding applying the error correction operational model on at least aportion of current blood analyte signal data.
 22. The method of claim21, wherein the operating the blood analyte sensing apparatus in thetraining mode comprises: (i) receiving time-stamped blood analytereference data; and (ii) collecting time-stamped calculated bloodanalyte sensor data.
 23. The method of claim 22, wherein the operatingthe blood analyte sensing apparatus in the training mode furthercomprises collecting time-stamped data derived from one or more in vivoancillary sensors.
 24. The method of claim 23, wherein the collectingthe time-stamped data derived from one or more in vivo ancillary sensorscomprises collecting data from one or more of a temperature sensor, apressure sensor, or a motion sensor.
 25. The method of claim 22,wherein: the collecting the time-stamped calculated blood analyte sensordata comprises collecting blood analyte sensor data subject to one ormore unmodeled systematic errors; and the receiving the time-stampedblood analyte reference data comprises receiving blood analyte data notsubject to the one or more unmodeled systematic errors.
 26. The methodof claim 22, wherein the generating the error correction operation modelcomprises generating blood analyte error data by at least calculating ablood analyte error value at one or more of a plurality of time pointscorresponding to respective one or more the time-stamped blood analytereference data.
 27. The method of claim 26, wherein the generating ofthe error correction operation model comprises identifying one or moreparameters that have a prescribed level of correlation to the bloodanalyte error data.
 28. The method of claim 27, wherein the generatingof the error correction operation model further comprises applying oneor more mathematical models to at least (i) the blood analyte errordata, and (ii) data relating to the identified one or more parameters.29. The method of claim 21, wherein the generating of the errorcorrection operation model comprises using at least one computerizedmachine learning process to generate one or more user-specific models.30. The method of claim 29, wherein the using at least one computerizedmachine learning process to generate the one or more user-specificmodels comprises using the at least one computerized machine learningprocess without input data indicative of an identification of one ormore physiological mechanisms as sources of blood analyte error.
 31. Themethod of claim 21, further comprising: generating a second errorcorrection operational model; substituting the generated second errorcorrection operational model for the error correction operational model;and using the generated second error correction operation model toprocess at least a portion of blood analyte signal data generatedsubsequent to the substituting.
 32. A computerized apparatus formonitoring a blood analyte level, the computerized apparatus comprising:data processing apparatus configured for data communication with ananalyte sensor apparatus implanted within a body of a subject; a storageapparatus in data communication with the data processing apparatus andcomprising a storage medium having at least one computer program storedthereon, the at least one computer program comprising a plurality ofinstructions which are configured to, when executed on the dataprocessing apparatus: (i) cause initial calibration of the analytesensor apparatus; (ii) cause the initially calibrated analyte sensorapparatus to operate in a first mode; (iii) generate an error correctionoperational model, the error correction operational model based at leastin part on the operation of the initially calibrated analyte sensor inthe first mode; and (iv) cause operation of the analyte sensor apparatusin a second mode, the operation in the second mode comprising at leastapplication of the error correction operational model to blood analytesignal data processed subsequent to entry of the analyte sensorapparatus into the second mode of operation.
 33. The computerizedapparatus of claim 32, wherein: the data processing apparatus isdisposed on a receiver apparatus external to the body of the subject;and wherein the generation of the error correction operation modelcomprises transmission of data collected via the analyte sensorapparatus during operation in the first mode, the transmission via awireless interface of the analyte sensor apparatus to the receiverapparatus, the receiver apparatus configured to perform or causeperformance of the generation of the model; and wherein the applicationof the error correction model on the blood analyte signal data comprisesapplication of model data received via the wireless interface from thereceiver.
 34. The computerized apparatus of claim 32, wherein: theanalyte sensor apparatus comprises an oxygen-based blood glucose sensor;the blood analyte signal data comprises blood glucose signal data; andthe processing apparatus and the storage apparatus are disposed on orintegral with the analyte sensor apparatus in an implantable formfactor.
 35. The computerized apparatus of claim 32, wherein thegeneration of the error correction operation model comprises:calculation of data related to a plurality of blood analyte errorvalues; and utilization of one or more machine learning algorithms on(i) at least a portion of the data related to the plurality of errorvalues, and (ii) data related to one or more candidate parameters, tomodel one or more previously unmodeled error sources related to theimplantation of the blood analyte sensor within the subject.
 36. Amethod of operating an implanted blood analyte sensor within a livingbeing, the method comprising: obtaining first blood analyte data usingthe blood analyte sensor, at least a portion of the first blood analytedata subject to one or more unmodeled systematic sources of error;obtaining reference data not subject to the one or more unmodeledsystematic sources of error; calculating a plurality of blood analyteerror values using the first blood analyte data and the correspondingreference data; identifying one or more parameters that have at leastone of a prescribed level or prescribed type of correlation to the bloodanalyte error values; generating an error correction model based atleast on the plurality of blood analyte error values, data relating tothe identified one or more parameters, and one or more mathematicalmodels; and obtaining calibrated blood analyte data by at least applyingthe error correction model to then-current blood analyte data.
 37. Themethod of claim 36, wherein the calculating the plurality of bloodanalyte error values comprises at least associating the first bloodanalyte data and the corresponding reference data at each of a pluralityof respective time coordinates.
 38. The method of claim 36, wherein theidentifying the one or more parameters comprises: identifying one ormore candidate parameters; associating data related to the one or morecandidate parameters with the plurality of blood analyte error values;and identifying an individual one or ones of the one or more candidateparameters meeting the at least one of the prescribed level orprescribed type of correlation to the plurality of error values.
 39. Themethod of claim 36, wherein the generating of the error correction modelcomprises utilizing one or more machine learning algorithms on at leasta portion of the plurality of blood analyte error values.
 40. The methodof claim 39, wherein the utilizing the one or more machine learningalgorithms comprises: utilizing a first machine learning algorithm togenerate a first error model data set; utilizing a second machinelearning algorithm to generate a second error model data set; evaluatingthe first error model set and the second error model set; and based atleast on the evaluating, selecting one of the first machine learningalgorithm or the second machine learning algorithm for the generating ofthe operational error correction model.